Disc IDs from Hybrid SACDs

Tags: #<Tag:0x00007fe3167d7f70> #<Tag:0x00007fe3167d7bd8> #<Tag:0x00007fe3167d7778> #<Tag:0x00007fe3167d74d0> #<Tag:0x00007fe3167d6fa8>

I was scrolling through some stuff in my subscriptions and ran across a release whose tracks all appeared to be multiple hours long (based on how the times were displayed). Thinking this was a case of input error, I went in to attempt to clean up the track times, but lo and behold, there was a Disc ID attached, so I couldn’t do anything about them!
I’ve never seen anything like this before.
Has anyone else ever seen a Disc ID like this? You can guess what kind of trouble it causes for editors attempting to clean up recordings from those releases.


Most hybrid SACD discIDs are wrong. From my experience, their TOC cannot be read properly by conventional CD/DVD players. I don’t have an SACD player, so I don;t know if they can read the TOC correctly.

1 Like

The SACDs I have will still give a “normal” discID calc when put in a standard CD player. The calculation is only on the CD side, not the SACD bit.

I don’t think the error is the SACD - it is whatever put that data together. Look at the extra colon where there should be a dot in the track and length times. It is clearly corrupted data.

When looking at the data I can see how to correct it. Notice how it is all just shifted left? That extra colon breaks it. If you list the “bad” discIDs you find, I can extract the data and resubmit it with correct formatting. As a test I’ll do the first one you linked


I’ve been experimenting - an AE may need to speed up a couple of my duff entries that I tried to delete on the example offered above. These need deleting: https://musicbrainz.org/edit/62589982 and https://musicbrainz.org/edit/62589708

It is a maths puzzle, so it made me curious. I can just about find a way to fix the error mathematically, but that isn’t going to help much. I doubt my hand rolled discID will match any real disk.

The fix I did was to manually create a TOC.

Firstly the time was just formatted - 52:38:05 instead of 52:38.05

Next the Sectors were wildly off - 4500 per second instead of 75.

So a bit of jiggery pokery and we have a valid TOC and discID.

I then used that to set track times. They now look much more sensible.

It is not a surprise that they don’t match the SACD side as I have seen that before.

Personally I think the best move is to delete the corrupted discID as it does more trouble than good.

Feel free to go ahead and delete my faked discID too. It is an experiment which I think leads to a correct result, but it is technically “fake data”.


I’d be happy to leave it in place, as long as you give your wonderfully detailed description in the edit note that adds it. :slight_smile: That way it will be easily available for a future editor to review the validity of and know that it isn’t an “organic” Disc ID in case it conflicts with an actual one. It may also turn out that it does match! Either way, the edit notes are a better way to have the lineage of the data explained, since the edit notes will exist for as long as the data(base) does, but this forum can be lost to time and accidents, like the old one did. :confused:


I’ll make it so - adding edit note to the “good fake” now.

I originally had deleted it, but the more I look at it the closer it feels to be “right”.

Happy to do any others. I am cracking a pattern here. I wonder if these have all be uploaded by the same user or at least the same software misfiring.

(It would help if someone could AE the two experiments to remove those: https://musicbrainz.org/edit/62589982 and https://musicbrainz.org/edit/62589708 )

1 Like

I have several Hybrid SACDs but none of them did produce weird Disc IDs.
Of course we speak about the Audio CD layer Disc ID, not the SACD layer itself, which cannot have Disc ID, as far as I know.

The problem here I think is the software the editor used to generate bad Disc ID and I think it could have been the same with a regular Audio CD.


Nice detective work - now we need to get out the Flaming Pitchforks and chase him down. Their are a number of “odd” entries in his history for SACDs.

It is funny if it is FooBar that messed it up - as that is the original meaning of FooBar (FUBAR).

Why is FUBAR not in the abbreviations list? Fudged Up Beyond All Recognition.

1 Like

I do have asked the editor what they used in their edit.
You say foobar2000 ? So maybe it’s a combination of foo_musicbrainz and a plugin, like this one, to access SACD ? I should try but I’m in the middle of changing PC.

Just confirmed this. Release not yet in DB. Will add it later. Done

1 Like

Hi there, yes, I used foobar2000 (1.5 b2) + foo_musicbrainz (0.3.9) + foo_input_sacd (1.1.3-2).
Sorry for the mess, I’m just feeling my way into all the possibilities of editing a release.

Edit: If there is a problem with calculating the hash, I could open a bug report on the SACD plugin author’s sourceforge page. I’d need some detailed info, though.


I should be able to prevent foo_musicbrainz from making these erroneous submissions. I’ll let you guys know when I’ve done it.

1 Like

@marc2k3 What component is actually responsible for calculating the disc ID here? Is it foobar2000 itself, foo_musicbrainz, foo_input_sacd or something else? Could whatever does the calculation be changed to make use of actual libdiscid?

1 Like

foo_musicbrainz does the DiscID calculation.

But I’m not even touching the code that does that. I’m just updating the code that won’t even let you open the menu option unless all tracks meet certain criteria. For example, this selection of tracks is OK…

and this selection is not…


But probably based on (in the case of @Jorgosch, erroneous) data provided by foo_input_sacd?

Well it’s just the exponentially larger number of samples per track that is the problem. They’re far too large to be from a normal audio CD rip.

Here’s an updated version which ensures the sample rate of all selected tracks is 44100 Hz for TOC submissions.

edit: there were already checks in place to make sure that samples % 588 == 0.


Ok, now I get it. So the disc ID calculation is not actually done by directly reading the CD TOC, but by relying on the metadata foobar is passing along with the tracks for playback, right? I guess this could lead to other wrong calculations. E.g. there might be no info on the pregap. Is this taken care of?

I didn’t write the code but you can poke around at it here…

IMO we could remove the Add Disc ID to MusicBrainz feature completely from foo_musicbrainz.
It’s always better to submit from Picard which uses the official lib.