I’ve recently discovered that even CDs, which I generally assumed to be the source of definitive acoustIDs, can be faulty and produce tracks whose acoustIDs don’t match that of tracks ripped with a properly functioning CD.
I have such a CD on an older computer I often use. It seems to work - tracks ripped from it sound okay, and there are no indications that it’s faulty eg. error messages. However, I became a bit suspicious of it a few months ago when it failed to extract valid ISRC tags (I use JonnyJD’s isrcsubmit.py script). It would find ISRCs, but they would have invalid characters and would be rejected.
I confirmed that its faultiness extended even to ripping this past weekend when I ripped a new CD. The CD was new to MusicBrainz but one track appeared on a different compilation, and had an acoustId. My newly ripped track generated a different acoustId, though (plus new acoustIds for the remaining new tracks).
I just ripped the same CD on my other computer, and now have a second set of acoustIDs for the same CD. (The one track that was already there has two as well; my good CD player generated a track that matched the acoustId that already existed for it).
So, just a warning. Even CDs can be a source for useless acoustIds. (I previously suspected that would only happen with analog sources eg. LPs or cassette tape). Apparently there is no effective error detection on a CD.
The CD in question is Dog Years by Tom Wilson, https://musicbrainz.org/release/6dc4e3b4-6f5e-4d66-bd96-1e61c273098f . Track 4, Talk of the Town featuring Roseanne Cash, also appears on a separate compilation so had an existing AcoustId.
You may be interested in AccurateRip or similar…
Even good drives don’t always produce completely accurate rips, especially if the disc is at all damaged. (Though they normally sound fine—even perfect, but digitally they’re slightly different.)
The basic idea behind AR is that you checksum your rip, and if you and someone else both got the same checksum, it increases the chance it’s right. The more different people who got that checksum, the more likely it is.
Several rippers (incl. morituri and EAC) have AccurateRip support.
You didn’t hear any sound glitches?
On the other hand, whether I rip lossless + stereo or highly compressed + downmixed to mono, I get the same AcoustID.
But yes, if the CD has damage…
No, I can’t really notice anything unusual listening to the files. Both have been encoded to .flac files, and when I extract the .wav file again they are the same size, though as expected they do not actually compare equal.
So, clearly there’s a flaw, but it seems to be a very subtle one.
Very interesting site - thanks. Clearly my assumption that a CD, if it worked at all, would flawlessly return the exact same data as was written is a bit off the mark.
I’m on Linux so the rippers on their site don’t work for me. I’m looking into morituri but it seems that it’s no longer being maintained, and I can’t find a build for my Debian Stretch system, Fortunately the CD on this machine seems to work well; its’ acoustIds consistently match existing releases I rip. I guess I’ll avoid uploading any acoustIds generated off of my old faulty system, so as to avoid polluting the acoustId database with more one-off acoustIds.
morituri was packaged in Jessie—that’s actually how I run it, on my testing/Buster system… I use schroot to maintain a Jessie chroot for it.
There is a maintained fork at https://github.com/JoeLametta/whipper … I haven’t tried that one yet. Someone has requested a Debian package, but no one has made one yet (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850541)
I actually have instructions on setting up the schroot (I had to do it on enough machines…) If you’re interested, I can make them available (along with the supporting config) somewhere.
I can vouch for whipper (being one of its contributors 
). If you’re comfortable using Python virtual environments, recent versions of whipper run just fine from within one of these (see whipper’s install instructions).
I think I’ll give whipper a try - looks like less work than setting up a chroot environment. Thanks for the tips.