second disc of multi-disc release adds isrcs to first disc

[JonnyJD]

same problem as: http://tickets.musicbrainz.org/browse/LMB-3

This is already fixed in a forked version of this script:
https://github.com/mineo/bin/blob/c381519c7a8080c3bbbdd7f1521b28c14d6d4e94/isrcsubmit-cdrdao.py
(first version on github already has this fix)

There the solution is to add an offset on the commandline, because the tracks from both discs are listed.

Possibly there is an automated solution like on the above mentioned ticket for the C++ isrcsubmit (not on github)

[JonnyJD]

I have to reopen this. It is true, that you can guess which disc number this is based on the DiscIDs attached on a release, but we are "screwed" if there are multiple DiscIDs per medium/disc.

Example:
http://musicbrainz.org/release/737c5eb3-0c88-4723-b229-6506af50ec3c/discids

This is no multi-disc release, but a release having two discIDs and seen by isrcsubmit as a multi-disc-release :-/

[JonnyJD]

In this case we can check if the number of tracks given for this release is the same as the number of tracks on the disc.

The real screw-up happens, when we have a true multi-disc release where the number of discIDs is greater than the number of actual discs.
We don't do anything wrong with first-disc/last-disc guessing, but the user can do something wrong when he gives the offset. Additionally there might be cases where we could guess, but don't do that, because it is the second discID of the first real disc, i.e.

[JonnyJD]

http://musicbrainz.org/cdtoc/attach?toc=1+17+342960+150+32832+64870+79542+100097+114215+125382+145377+159060+174005+188955+198837+213327+229370+244587+279992+290152&tracks=17&id=tAftjDp33rl8kCVr91UxTHnju20- (best of the the doors, limited edition with bonus disc) is an example for the real-screw up.

This is also an example for #5
If you take the second release found you have a 4 discIds, our discID being the second disc. 3 of the IDs are from disc 1 (like ours) and 1 ID is for the bonus disc.
See: http://musicbrainz.org/release/26f83425-ecbe-3ebd-b393-32d28d1a56de/discids

So we have the first disc in a 2-disc setup, having 17 tracks. We get 21 tracks on the release because of the 4-track bonus disc.

2 questions for cases like these:

1. Can we do anything to guess the offset?

   How do we find out, that all of the 3 first discIDs are just for one disc?

2. The correct offset is 0, but how do we help the user to find that out?

Of course, if this gets too difficult we could also rather start preparing another isrcsubmit with real NGS support. See #6.

[JonnyJD]

79494b6 uses release events to distinguish releases.

We could do something similar: When the release events are different, then the corresponding discIds belong to different releases (in NGS) and are not both part of the same multi-disc-release.

On the other hand we can only get this release event information when we issue one release search per discId in the curren release. Doubling or tripling the impact on the server (and might get throttled).

It would be easier if we

a) fetch some direct XML from the webservice (possibly also from ws 2)

b) just give a corresponding link for the browser, so the user does have proper information. Example: http://musicbrainz.org/release/add9be65-7960-4fb7-beac-c4c34243b095/discids