display releases’ catalogue numbers when « This Disc ID is ambiguous » at release selection about musicbrainz-isrcsubmit HOT 10 CLOSED

That should be possible, yes.

I just don't know if there are many cases where this helps. "major" releases mostly have a cat# that is a part of the EAN anyways.
"independent" releases without barcodes normally don't have ambiguous releases.

I could try to read the MCN from disc, which should be the barcode. And filter the release selection based on that (unless there is nothing left hen). Though that needs changes in every backend, obviously.

from musicbrainz-isrcsubmit.

I think it's a good idea to show the MCN, but don't use it to filter. The MCN may be wrong (either from the source, a bad pressing, or from corruption of the disk) and the barcodes on MusicBrainz may be wrong. There's also the chance that one of the two has a leading 0 vs. a non-leading zero (EAN vs. UPC).

Showing the cat. no. as well may be useful anyway, even if most cases won't have a use of it.

from musicbrainz-isrcsubmit.

Okay.. displaying the MCN at the ambigous disc ID selection is a bit difficult.
We start the backend after the selection and libdiscid doesn't export the MCN.

And displaying the MCN afterwards doesn't really help, or does it?

from musicbrainz-isrcsubmit.

Afterwards it doesn’t help.
I’m mainly editing japanese releases where you don’t really care for JAN/EAN/barcodes as they use standardize (simple ABCD-1234) kind of catalogue numbers that are very easy spots.
There also are non japanese releases where catalogue numbers are clever.
I thought you were using the WebService…

from musicbrainz-isrcsubmit.

Yes. I am using the webservice.
To be explicit.

I gather the disc id with libdiscid (from disc)
Then I query MB for matching releases (for this id). At this point I get the release events with barcodes, dates and possibly also cat#s.
After that, I use a backend to scan the disc for ISRCs. The backend often also finds an MCN (which should be a EAN/UPC), but at that point you have already chose wich release you want to attach the ISRCs to.

So what you are saying is:
cat#s are shorter and easier to read than barcodes and therefore should be listed at release selection.

Yes, I will consider this. It's mostly a question of layout and how many numbers I can display without the user getting dizzy.
One thing that is better with barcodes, they all have a VERY simirlar length. So it looks a bit more tidy.

from musicbrainz-isrcsubmit.

Oh I did not know MCN, I indeed asked for catalogue numbers from MB releases. :)
If you put them, put them as last column, so the length difference (or lack of catno) is not too much of a burden.
See how catalogue numbers are very clean and handy :
http://musicbrainz.org/artist/1f245b43-f9ba-4d02-a70b-cd08a99cd1c9/releases
http://musicbrainz.org/artist/88d8f38f-adb4-48a0-8c1f-ec34f2a675ff/releases
BTW if you have several catalogue numbers you can display only the first one (when sorted alphabetically) if it’s better.

from musicbrainz-isrcsubmit.

Ah, there was another reason why I didn't include the cat#s: They are not exposed in release queries with ws/1.

Example:

http://musicbrainz.org/ws/1/release/?discid=BAtiIvMk0ZK0JL_d1G85VuayiU0- has no cat#

http://musicbrainz.org/cdtoc/BAtiIvMk0ZK0JL_d1G85VuayiU0- does

So this depends on #6 or a bugfix on the server side.

Technically we could fetch each release by MBID and get the cat#, but this would take as many requests as releases are found.

from musicbrainz-isrcsubmit.

I created a ticket for the Web Service: http://tickets.musicbrainz.org/browse/MBS-5695
Not really sure if non-critical issues in ws/1 are considered at all.

from musicbrainz-isrcsubmit.

When catalog numbers are exported again by the web service, they will be displayed. The corresponding change was made.

from musicbrainz-isrcsubmit.

Cool, thanks :)

from musicbrainz-isrcsubmit.