6 ms·

Most of the TLMC rips are range rips with unclear CUE data, which makes it difficult or impossible to verify they were correctly ripped. For this album in part

Most of the TLMC rips are range rips with unclear CUE data, which makes it difficult or impossible to verify they were correctly ripped. For this album in particular, the audio CRCs of the other tracks don't match up between TLMC and a fresh rip: TLMC: 01.wav: 9A5E3226 02.wav: 577A675B 03.wav: 3548C299 04.wav: E5DEC006 05.wav: D33AC4AE 06.wav: 7427AC6F 07.wav: 83A58517 08.wav: 0DCA8419 09.wav: 703BAEAC My rip: 01.wav: 565F2B5A 02.wav: E916B3A2 03.wav: A595BC09 04.wav: D989F0D6 05.wav: C6A2DD2B 06.wav: C8403284 07.wav: D01D6BC4 08.wav: 8786C1AA 09.wav: 1E3641DD

scrollaway 8y ago
Is there such a thing as an audiodiff to tell how different they are to yours?
- jmillikin 8y ago
  Yes: you can use Audacity (https://www.audacityteam.org/ 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.
  - thr0w__4w4y 8y ago
    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.
- dylan604 8y ago
  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.
  - tomc1985 8y ago
    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
- deleted 8y ago
  [deleted]
- tialaramex 8y ago
  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.
- r721 8y ago
  Audio DiffMaker: http://libinst.com/Audio%20DiffMaker.htm http://libinst.com/Audio%20DiffMaker.htm
gwern 8y ago
But do they sound any different?
- jmillikin 8y ago
  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.
  - plg 8y ago
    I bet you could, given good audio equipment (good DAC/amp/speakers or DAC/amp/headphones)
- userbinator 8y ago
  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.)
  - gwern 8y ago
    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.
- rsync 8y ago
  "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 ...
rococode 8y ago
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!)
aidenn0 8y ago
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.
zuzzurro 8y ago
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 http://cue.tools/wiki/Main_Page Not the author but a very happy customer

scrollaway 8y ago

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

jmillikin 8y ago
Yes: you can use Audacity (https://www.audacityteam.org/ 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.
- thr0w__4w4y 8y ago
  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.
dylan604 8y ago
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.
- tomc1985 8y ago
  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
deleted 8y ago
[deleted]
tialaramex 8y ago
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.
r721 8y ago
Audio DiffMaker: http://libinst.com/Audio%20DiffMaker.htm http://libinst.com/Audio%20DiffMaker.htm

gwern 8y ago

But do they sound any different?

jmillikin 8y ago
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.
- plg 8y ago
  I bet you could, given good audio equipment (good DAC/amp/speakers or DAC/amp/headphones)
userbinator 8y ago
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.)
- gwern 8y ago
  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.
rsync 8y ago
"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 ...

rococode 8y ago

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!)

aidenn0 8y ago

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.

zuzzurro 8y ago

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 http://cue.tools/wiki/Main_Page Not the author but a very happy customer