Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

JonnyJD opened this issue Feb 4, 2012 · 4 comments

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

JonnyJD opened this issue Feb 4, 2012 · 4 comments


Copy link

JonnyJD commented Feb 4, 2012

same problem as:

This is already fixed in a forked version of this script:
(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)

@ghost ghost assigned JonnyJD Feb 4, 2012
@JonnyJD JonnyJD closed this as completed in ec143a5 Feb 5, 2012
@JonnyJD JonnyJD reopened this Feb 5, 2012
Copy link
Owner Author

JonnyJD commented Feb 5, 2012

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.


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

Copy link
Owner Author

JonnyJD commented Feb 5, 2012

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.

Copy link
Owner Author

JonnyJD commented Feb 5, 2012 (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.

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 added a commit that referenced this issue Feb 6, 2012
When the number of tracks reported on the disc and the number of tracks
given on the release match, we do not need to check the list of discIds.
This just means we have multiple discIds for a single disc.
There is only a problem when there is another "real" disc, but then the
track counts would not match.
Copy link
Owner Author

JonnyJD commented Feb 6, 2012

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:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

1 participant