Comparing two WAV files?

[Sineira]

I wan to compare two WAV files. One ripped straight from a CD and one recorded via SPDIF.

I'm not interested in wave forms, I want to see bit level differences (there should be none ideally).

 

I first tried using Diffmaker but just get nonsense results, more or less same as the original file, since the start point is a bit diffuse I was hoping it would be able to align the two and make a comparison of sorts?

 

What could I be doing wrong?

[wgscott]

just use a checksum: sha1 or md5sum

[Sineira]

Well that won't work since there is no defined start or end point for the files. The start and end of the files will not be exactly same.

[Audio_ELF]

Well the two files will not necessarily be the same.

 

Your probably only comparison method would be load both files into a audio editor (such as Audacity), align the start point and then invert one ... the sum of the two files should then be silence.

 

Eloise

[esldude]

You can make alignment of the files easier once you have it ripped. Take it and open it in Audacity, you can zoom in until you see each bit. Place a marker bit near the beginning and end of the file. There is a ' bit marker' tool in Audacity. Place one bit to maximum. That will give an easy to find place to align the file later.

 

Then once you record it finding and aligning the two single bits to max will be easy in Audacity. Then invert and see what is left by using "mix and render". Alternatively you can chop the ends off the file at the marker bits for both files and get a MD5 or other checksum. If identical the checksum will be the same. If you have volume control or other factors involved they may not match.

 

Now these approaches will work if you are recording the digital output of the SPDIF stream. If you are recording the analog output of a DA converter, then you will never get bit for bit results due to analog noise and time delays.

 

If you fill us in on what you are checking we might be able to give more help.

[mac_and_dac]

I wan to compare two WAV files. One ripped straight from a CD and one recorded via SPDIF.

I'm not interested in wave forms, I want to see bit level differences (there should be none ideally).

 

I first tried using Diffmaker but just get nonsense results, more or less same as the original file, since the start point is a bit diffuse I was hoping it would be able to align the two and make a comparison of sorts?

 

What could I be doing wrong?

 

There are two ways of doing this:

 

1) Use a Hex Editor to open both files. Ignore the first 44 bytes (Wav header) and then look at the first meaningful run of hexadecimal values. You should see pattern matches.

 

2) If you are struggling to do this visually, then find a friendly programmer and set them the challenge of comparing the two files. Not as a 'diff' or using a checksum, but by buffering the data in both files. Say we create Buffer A and Buffer B. Ignore the first 44 bytes in both buffers, then use an incremental counter on Buffer A to take each subsequent hex value and look for matching runs. Every time there is a hex match, compare A+1 with B+1. If you get a match again, then do A+2 and B+2. And so on. If there is no match, increment the counter for Buffer A and do it over. Well, there's a bit more to it than that but I don't have the time to write the full pseudo-code, but I hope you get the gist. If the L/R PCM data in the files is bit-equivalent, then a print of the counter should show a number in the tens of millions. There is probably a smarter way of solving the problem, but a 'brute force' approach like the above will get the job done.

 

If you are worried about bits getting 'lost' or corrupted, then I wouldn't. You will hear it. As an experiment, use a hex editor and change just a single hexadecimal value out of all the many millions that make up the wav file. I guarantee that you will hear the resultant pop or click during playback.

 

As already stated in an earlier post, it would be interesting to know what you are looking to achieve with the comparison.

[Paul R]

I think the files would be too different for that to work. (i.e. different sizes.)

 

I wonder if just stripping off the first 44 bytes and running it through diff would work?

 

tail -c +44 file1 > t1

tail -c +44 file2 > t2

 

diff t1 t2

 

-Paul

[mac_and_dac]

^^ That approach will work if the PCM data is identical, so it's a good first test for sure.

 

I guess the problem is that a ripped redbook file may not look like a file generated from an S/PDIF stream. I haven't thought about it too deeply, but I wonder if the bit stream could provide leading and trailing bits (e.g. a run of zeroes) that are also captured? Diff'ing on non-ascii files will probably not produce the kind of meaningful output you get on text files if there are differences. I think the diff binary just tells you that the files differ.

 

I guess we need to know more about how the file is captured.

 

My approach is a bit over-engineered (I would call it 'belt and braces'!), but I was hoping to at least catch the first 'meaningful' bit and be able to prove the bit equivalence of the PCM data (wherever it starts).

 

Still curious to know what the OP objective is!

[sandyk]

Still curious to know what the OP objective is!

 

Perhaps he has a multi disc CD player and is investigating the possibility of expediting ripping of his CD collection ?

IIRC, some software such as that from some earlier Creative cards were able to rip individual tracks instead of an ISO ?

[mac_and_dac]

Perhaps he has a multi disc CD player and is investigating the possibility of expediting ripping of his CD collection ?

IIRC, some software such as that from some earlier Creative cards were able to rip individual tracks instead of an ISO ?

 

Exact Audio Copy is perhaps the best way to do it, if that's the case: it will rip a whole Redbook CD to individual lossless .wav files in 5-10 minutes. S/PDIF is a real-time feed, so probably not the quickest way to capture the bits.

[sandyk]

Exact Audio Copy is perhaps the best way to do it, if that's the case: it will rip a whole Redbook CD to individual lossless .wav files in 5-10 minutes. S/PDIF is a real-time feed, so probably not the quickest way to capture the bits.

 

Agreed. However one could load CDs into a multi disc player then carry on with whatever else they were doing, IF it was practical.

[thesurfingalien]

I wan to compare two WAV files. One ripped straight from a CD and one recorded via SPDIF.

I'm not interested in wave forms, I want to see bit level differences (there should be none ideally).

 

I first tried using Diffmaker but just get nonsense results, more or less same as the original file, since the start point is a bit diffuse I was hoping it would be able to align the two and make a comparison of sorts?

 

What could I be doing wrong?

 

I believe I have a small tool that more or less does what you need, but I have to look for the code and modify it a bit to make it do exactly what you need... If you do not mind working from a command-prompt, that is.

[Paul R]

^^ That approach will work if the PCM data is identical, so it's a good first test for sure.

 

I guess the problem is that a ripped redbook file may not look like a file generated from an S/PDIF stream. I haven't thought about it too deeply, but I wonder if the bit stream could provide leading and trailing bits (e.g. a run of zeroes) that are also captured? Diff'ing on non-ascii files will probably not produce the kind of meaningful output you get on text files if there are differences. I think the diff binary just tells you that the files differ.

 

I guess we need to know more about how the file is captured.

 

My approach is a bit over-engineered (I would call it 'belt and braces'!), but I was hoping to at least catch the first 'meaningful' bit and be able to prove the bit equivalence of the PCM data (wherever it starts).

 

Still curious to know what the OP objective is!

 

Diff can handle Binary differences, or run it through od first, or anything similar. Or you can convert both files to LPCM of course.

 

Still, I suppose a little utility to do thst would be worth the time to write ad release.

[mac_and_dac]

I would like to know how to capture an S/PDIF feed, as Sineira is doing. Can anyone recommend a way of doing this?

[sandyk]

I would like to know how to capture an S/PDIF feed, as Sineira is doing. Can anyone recommend a way of doing this?

 

 

Many Soundcards offer this facility, and may even include measurement software.

 

[mac_and_dac]

Thanks! Will investigate.

[mac_and_dac]

Ok,

 

I ran a test today, playing a 16/44.1 PCM .wav file through Toslink S/PDIF into the digital input of my Mac Mini, and captured it with Audacity.

 

I looked visually at the bytes through a Hex editor, and from what I could tell they did not match up.

 

I suspect that the Mac Mini sound card is converting the stream to analogue, which on recording to the output .wav file is (of course) converted back into digital. Another less likely but possible explanation is that my music player is modulating the digital signal before output to the sound card.

 

Any comments welcome!

 

I hope my analysis is wrong somewhere, as I think it would be great to be able to move music bit-perfectly from one source to another via S/PDIF, which should theoretically be possible.

[goldsdad]

Ok,

 

I ran a test today, playing a 16/44.1 PCM .wav file through Toslink S/PDIF into the digital input of my Mac Mini, and captured it with Audacity.

 

I looked visually at the bytes through a Hex editor, and from what I could tell they did not match up.

 

Since you're using Audacity, anyway, use it (as recommended by Audio_ELF and esldude above) to actually calculate the difference instead of laboriously and unreliably (no offence intended) eyeballing two files in a hex editor. I don't mean for you to listen to the difference track in order to determine whether it is pure silence or not. I mean Audacity can calculate and display differences of as little as the least significant bit of a sample.

 

I suspect that the Mac Mini sound card is converting the stream to analogue, which on recording to the output .wav file is (of course) converted back into digital.

 

When recording a digital input to a file, the audio remains in the digital domain. The Mac will convert digital to analogue only when producing an analogue output.

 

Another less likely but possible explanation is that my music player is modulating the digital signal before output to the sound card.

 

Any comments welcome!

 

You haven't revealed any details of the player, but you'll need to ensure the player application and OS are both set to perform no signal processing, i.e. produce bit-perfect output at 44.1 kHz in your case. Likewise, on the recording Mac, ensure Audacity is set to record at 44.1 kHz and ensure the audio input rate is set to 44.1 kHz in Audio MIDI Utility.

 

 

I hope my analysis is wrong somewhere, as I think it would be great to be able to move music bit-perfectly from one source to another via S/PDIF, which should theoretically be possible.

 

Surely, you don't intend to do that as a means of transferring files between computers, so exactly what do you have in mind?

[mac_and_dac]

Thanks goldsdad for the advice, all really useful.

 

Ref. comparing differences in Audacity, I wasn't aware it had that function. It's good to know and I will try it. I will see also if there is a way to get Audacity to start recording only when it receives a signal. (At the moment I press the record button manually, and of course pick up meaningless silence until I have clicked Play on my source ...)

 

Thanks also for the information on the Mac digital conversion. This is excellent to know.

 

The music player I was using is MPD, which is set to 100% volume which I have tentatively assumed is the equivalent of bit-perfectness. If anyone knows better, please tell me as I've struggled to find information on MPD configuration.

 

My OS is the Raspbian Wheezy flavour of Linux on a Raspberry Pi, which I doubt would intervene to manipulate the bit stream but, again, I am willing to be corrected.

 

Regarding file transfer, no - I certainly wouldn't try to transfer files using S/PDIF. I've learned to use the Copy command! What I am interested in is taking digital feeds from non-file based sources, e.g. internet radio, in order to be able to capture them with minimal rendering from other modules. The only reason I am interested in this is because when I capture Spotify and the like currently to create .wav files on Windows 7, evidence suggests that I am not recording the native bit stream: for instance, the Windows volume control affects the recorded signal level, which is incredibly annoying. (This is using my own software, written using wavOut functionality from the Win32 API.)

[goldsdad]

For recording with your Mac mini try Audio Hijack Pro

 

Rogue Amoeba | Audio Hijack Pro: Record Any Audio On Mac OS X

 

 

[mac_and_dac]

For recording with your Mac mini try Audio Hijack Pro

 

Rogue Amoeba | Audio Hijack Pro: Record Any Audio On Mac OS X

 

 

Thanks again, goldsdad!

 

I downloaded AHP earlier today and was able to 'hijack' a test S/PDIF bitstream from my Raspberry Pi. I then compared the captured .wav file with the original .wav file played through MPD. The comparison showed bit-equivalence.

 

This is great for two reasons:

1) It means that I can now be sure, rather than suspecting, that the '100% volume' setting of MPD is essentially a 'bit-perfect' setting

2) I now know that, if I use OSX, I can capture digital input without the 'intrusion' I have been experiencing on Windows 7

 

This is a great step forward for me on my projects, so a big thank you again.

[goldsdad]

You're welcome!

[G0bble]

The music player I was using is MPD, which is set to 100% volume which I have tentatively assumed is the equivalent of bit-perfectness. If anyone knows better, please tell me as I've struggled to find information on MPD configuration.

Volume has nothing to do with bit perfect playback. Also in my listening experience the sound is inferior when the volume control is enabled.

 

If you use Linux a good way to compare two binary files is the cmp command.

My OS is the Raspbian Wheezy flavour of Linux on a Raspberry Pi, which I doubt would intervene to manipulate the bit stream but, again, I am willing to be corrected.

 

That is dependent on your mpd.Conf file not the os.

What I am interested in is taking digital feeds from non-file based sources, e.g. internet radio, in order to be able to capture them with minimal rendering from other modules. The only reason I am interested in this is because when I capture Spotify and the like currently to create .wav files on Windows 7, evidence suggests that I am not recording the native bit stream: for instance, the Windows volume control affects the recorded signal level, which is incredibly annoying. (This is using my own software, written using wavOut functionality from the Win32 API.)

 

You can get bit perfect audio out of mpd, but it takes a bit of reading up.

 

HTH

 

Sent from MiPad