The CUE data in TLMC is a real bummer. I don't know if it's my music player, Clementine, but a good portion of the tracks I listened to in TLMC didn't advance correctly and instead just kept playing with the metadata of the first song in the album that I listen to. At this point I've mostly just given up on it... It took me 3 months to download it too, haha (curse you, Comcast 1TB monthly data limit!)

Is there such a thing as an audiodiff to tell how different they are to yours?

Yes: you can use Audacity (https://www.audacityteam.org/) to "diff" two waveforms by subtracting one from the other.

For comparing .wav files you can also treat them as plain binary data, and use standard diff tools. For example I used `cmp -l` to count differences between rips, and `vbindiff` to view them.

Thanks for mentioning vbindiff. I examine/compare binary files a lot (reverse engineering for security) and I've used a bunch of tools, but somehow I've never come across vbindiff.

First thought: Invert the phase of one of the tracks 180 degress, then sum them together. Anywhere the is a bump in the waveform would show a difference between the two sources.

Funny, you can use this technique sometimes to pull clean vocals (for remixing) from certain kinds of music (they have to be panned center in an otherwise stereo mix):

a) reverse one of the channels and them sum them and you'll sum will contain only stereo data

b) reverse and sum (a) with the original track to get only the mono content

Finding the signal difference is easy, the nature of PCM means we can just subtract one recording from another.

However human hearing doesn't just import the signal, the initial processing is done during acquisition itself. Psychoacoustic lossy audio encodings like MP3 rely on this, an MP3 sounds to you very much like the original but a naive audiodiff would find huge differences.

Audio DiffMaker: http://libinst.com/Audio%20DiffMaker.htm

But do they sound any different?

You're asking the wrong person: I can't reliably tell the difference between FLAC and YouTube.

When you've got a .wav file open in a hex editor, it's no longer really about the music itself.

"But do they sound any different?"

As a fellow ripper of physical CDs in 2018, the point is that a correct rip of CDDA from the CD is the one and only way to be sure you won't ever have to rip that music again.

Any other file, any other delivery/download mechanism, any other format ... you'll be fooling around with that song again sometime. But not if you have the correct, error free rip of the WAV/PCM from the CD.

So it's really not about the sound vs. some other format ...

> you'll be fooling around with that song again sometime

I've been ripping in AAC 256kbps for 15 years now and have yet to see any reason to revisit any of those CDs. Even if a more efficient encoding mechanism gains mainstream support, I'll just use that for new rips only since storage is cheap enough.

> since storage is cheap enough.

That's exactly the point. Using anything but a lossless codec for ripping music is an unwise decision.

It's not that cheap though. My laptops 1 TB SSD can comfortably store 60 GB of AAC files and I forget they even exist, but if those were uncompressed, the 300 GB they take up would be a major problem.

I'm aware - my collection is nearing 1 TB of lossless music at this point.

However I store it on a local NAS as well as a an external SSD (in case I need it in a portable way, which rarely happens) - I opted for an expensive SSD because it's very light, small and portable, but a traditional external drive would handle music just fine if price is a major concern.

At the end everyone has different requirements, but since I consider ripping a huge amount of music a major task I wouldn't want to repeat, I'd make sure I do it right from the beginning - and opting for a lossy format doesn't fit into that idea.

also being lossless you are futureproofed on new formats you might need to convert to.

I mantain both: a tree of lossless files and an exact copy already encoded as 320kbit mp3 that is automatically mantained (just because i can quickly cram those into a usb thumbdrive and they'll play anywhere -- i can't say the same about flac support).

o/

How do you _automatically_ maintain a shadow-library? I always argued against the parallel-collection-approach as you'll likely run into inconsistencies while trying to maintain it manually.

I'm glad iTunes offers to transcode my lossless collection to lossy AAC on the fly before syncing to the iPhone (yes, some people still do that).

Of course my concern is storage in mobile devices. Yours seems to be flac support? However is that really an issue these days? I use ALAC (due to using iOS devices), but even then I never run into compatibility issues. Any worthwhile software/hardware supports either format - with Apple being the big outlier requiring ALAC.

> also being lossless you are futureproofed on new formats you might need to convert to.

Part of my original point was that I've been using AAC exclusively for 15 years now, and with all the content encoded in AAC now I don't see support for it disappearing in the next 15 either.

Probably not, but now AAC support is forever a fixed, inevitable requirement for you.

As another fellow ripper of physical CDs - is there a good way to check for quality of my rips besides looking at the bitrate and listening to all of them (talking mp3s here, of course)? I'm not interested in perfect lossless quality, but I'm quite sure I should re-rip the CDs I did 10-15 years ago, but for VBR mp3s it's kinda hard to decide what is 'good enough', as compared to say 128kb/s rips - so I'm looking for a scriptable way to give me a rough "keep/maybe/definitely throw away" metric...

Rephrasing the question: What are people typically using these days when not going for FLAC? Some of my mp3s are definitely from the "HDD space is expensive" age 15+ years ago...

MP3, with LAME (-q0). A couple of the really old rips used average bit rate instead. Will probably re-rip those at some point, but the rest sounds fine to my ears.

Usually the formats are FLAC, 320, V0, V3.

I've never seen anyone use V3 for VBR rips, usually V2.

The article says "there were about 20,000 bytes different betwen each rip", which if it happened in one stretch corresponds to ~113ms of audio. Depending on the exact nature of the error and how it changes the samples, it may be very obvious (e.g. a 113ms burst of silence or static) or inaudible (one different bit in a few hundred thousand --- probably won't even get past the lowpass filtering on the DAC.)

That 20,000 bytes might not be a real difference, as I understand OP. It sounds like it's the XOR or Hamming distance, byte or bitwise - in which case you could get very large differences in the number by very small errors like dropping 1 bit (thereby putting all following bits out of alignment) yet the perceptual difference would be unhearable (and maybe not exist at all depending on how the encoding works). eg 0101010 vs 101010. You'd want to calculate some sort of edit distance which takes into account the possible bit flips and burst errors to see how big the real delta is. And of course, as pointed out in the other comments, for all of OP's hard work, there's no way to know which source is right or how many errors remain in his final version.

This matters for long-term music archival when you want to sample it and play with the audio, which could exagerrate the defects as you edit it. We should preserve pristine source material.

Are you aware of CUETools, CUERipper and the ctdb for ripping and repairing? Just wondering if it would have helped your case. It sure helped me recovering some damaged old cds. Available at http://cue.tools/wiki/Main_Page Not the author but a very happy customer

If the TLMC is lossless and gapless, then you could paste the last few seconds of 2, all of track 3, and the first few seconds of track 4, then search for an offset that yields a minimum diff.