I had picard lookup a cd that was number two in a two CD set that I had just added: https://musicbrainz.org/release/3c8771b6-9a69-473f-b468-260dedfcf88a. It reported the item was not found. As I had just added the release I expected this. But when I clicked on “Submit Disc ID” I got an error page with:
Bad request
Sorry, there was a problem with your request.
Error message:The provided CD TOC is not valid. This is probably an issue with the software you used to generate it. Try again and please report the error to your software maker if it persists, including the technical information below.
Some more status. I am ripping the cd using abcde. I ask abcde to include the mbdiscid in the flac metadata. abcde has put in, “bbX6FcoYAXbzxu1HcWVHB7SG0fY-”. I tried using that on the query string but it gave me a similar “Bad Request” error.
From within Picard, how have you gotten the disc ID? Have you looked up directly the CD in your drive, or was this from a ripper log file? If the latter, can you please share the log file?
CD was in drive, and I had picard lookup /dev/sr0. Have never used a ripper log file. I can provide if you can tell me how to create one. My standard procedure is to verify that the disc is in musicbrainz or, as here, add it using picard, then rip the disc directly to .flac using abcde.
I found a utility for “calculating” the mbdiscid at: Disc ID Calculation - MusicBrainz . Search for “mbdiscid” on the page. I had to add several perl modules, libdevice-cdio-perl, libdigest-sha-perl and libgetopt-argvfile-perl, then I had to change the “mbdiscid” utility, which was using a perlmodule “SHA1” , which I guess was replaced by a perl module called “SHA”. After that I calculated the mbdiscid for the disc that was successfully added to the musicbrainz, and the value matched that inserted in the .flac metadata. I then used the utility on the disc that didn’t work, and the value was the one submitted on the Bad Request (and not the one inserted by abcde).
This is one of those rare cases where the CD TOC reports track numbers not starting at 1. Instead the first track number is 11. 11 20 318150 150 36957 49607 70087 93327 148470 162712 187247 217280 258490 is the data from the TOC, with first track number 11, last track number 20, followed by the total sectors on the disc and offsets to the tracks in sectors.
Calculating the disc ID for this gives BKo_GszYMu.nSJjQHgMUbD7HWx4-. The MB server however rejects such disc IDs. This is something I think should be changed, and there is an open ticket for it:
abcde does something interesting: When calculating the disc ID it shifts the tracknumbers to 1, so it uses 1 10 318150 150 36957 49607 70087 93327 148470 162712 187247 217280 258490 for calculations, which yields the disc ID bbX6FcoYAXbzxu1HcWVHB7SG0fY-. This theoretically would be possible to submit to MB with https://musicbrainz.org/cdtoc/attach?id=bbX6FcoYAXbzxu1HcWVHB7SG0fY-&tracks=10&toc=1+10+318150+150+36957+49607+70087+93327+148470+162712+187247+217280+258490&tport=8002. It likely would help with abcde being able to lookup the CD, and exact times from disc ID could be set on MB. But it would not help with other tools calculating the disc ID with the actually reported disc numbers.
But I think the server side should be fixed and submitting such TOCs with first track > 1 should be possible.
The only hardware I have to play a cd is a computer with a cd-rom in it. All my other CD players have packed it in. VLC is probably the only program I have that will play the disc directly, and it lists tracks 1-10.
As an interesting side-note, the back of the album cover lists tracks 1-20, not disc 1, tracks 1-10 & disc 2, tracks 1-10. The disc also has “11-20” printed on it. I will guess the decision to mark the tracks as 11-20 on the second disc was deliberate.
I am unclear whether it is correct in the specification or not. I have no idea if this is covered in any specification. But looking at this with only the information I have from here, I have a lot of questions. If the first track should always be track 1, then why include a data field for the first track? The only thing that can happen is that field can be wrong. That in turn suggests that the data field for the first track is legal. And then why is there a field for last track? You can count the tracks from the TOC, so this implies there should be some meaning for the “last track” field. I am guessing that CDs are allowed to have more tracks on them than can play on a CD player, and that the “first track” and “last track” fields indicate the first and last .wav tracks that are meant to be played on a CD player. The other tracks which lie outside those bands are meant for other purposes, e.g. data. Based on that I will guess it is likely that marking a disc as tracks “11-20” then putting only ten tracks total on the disc is a violation of whatever specification applies, i.e. it has to be true that 1 ≤ first track field ≤ last track field ≤ total number of tracks on disc. But this is only my guess; I do not know what the relevant specification says.
I am not an expert, but based on my work with other discs none of this looks wildly out-of-line. abcde had no trouble ripping the disc. I have not listened to it through, but the tracks I have played seem reasonable.
59660 [13:15.35] 258340 [57:24.40] no no 2
TOTAL 318000 [70:40.00] (audio only)
Again I don’t see anything remarkable other than listing the track numbers as 11-20. The tracks are somewhat long, but that matches how they appear on the listings on the cd.
Looking at the TOC from cdrecord and cdparanoia the first track is actually 11, and everything else looks normal.
I am not an expert either, but it does not appear to be illegal, just not recommended. It appears if the mastering software allows starting at greater than track#1 then it can be done, and at that point it is up to CD reader/player to read it, and some may behave differently depending on how old they are. While not typical behavior I do agree with https://tickets.metabrainz.org/browse/MBS-7136 and will vote for it.
The TOC of an audio CD is explicitly states the first and last track number. And AFAIK the Red Book Standard, which defines the technical details of an audio CD, allows the starting track number to be larger than 1. Track numbers are just limited to be in the range of 1-99 and they have to be consecutive without gaps.
In practice it is rather rare for the first track number being larger 1. I personally never did hold such a disk in my hand. And I think that is the number one reason why support for this is lacking.
But there are of course cases of this often enough that this comes up regularly. Usually this seems to happen for multi-disc compilations, and it makes some sense. But it only works as long as the total number of tracks is not more than 99. So you won’t see this being done on one of thos huge Bach box sets or such
libdiscid, the software library which is the primary implementation of the MusicBrainz disc ID algorithm, does handle first track greater 1.
I think right now this is just a server side MB issue that never got solved.
I wonder how other software in our ecosystem such as EAC and cuetools (which I use) handle this. Since others are tied to this database what is the correct disc ID to store, the one starting at track#1, the one starting at track#11, or both? In any case the release(s) in question should have sufficient annotation to explain this.
I had another thought concerning the presentation of the release in MB. While I have not tried it myself, I think you can manually edit the track numbers for the second medium to be 11-20, if so, is that the correct thing to do?
I would say “yes” as it is “artist intent” as to how they present the CD. When I saw this discussion it feels like something done for the person ripping a CD to FLAC\MP3 as it naturally separates the tracks.
