Program to compare 2 audio files?

[Ralf11]

Is there a (free?) program that can do a bit for bit comparison of 2 files, both of which are in Apple Lossless?

 

I did 2 rips of a beater CD of Song for a Seagull - one using iTunes, and the other using XLD.  I'd like to see how the bits came out w.r.t. errors.

[kumakuma]

2 hours ago, Ralf11 said:

Is there a (free?) program that can do a bit for bit comparison of 2 files, both of which are in Apple Lossless?

 

I did 2 rips of a beater CD of Song for a Seagull - one using iTunes, and the other using XLD.  I'd like to see how the bits came out w.r.t. errors.

 

I don't think that you want to do a bit-for-bit comparison as there may be differences in the metadata of the two files.

 

Instead you can use xACT to generate .st5 checksums of the uncompressed audio portion of the files. 

 

If xACT doesn't work with Apple Lossless, use XLD to convert both to flac.

 

More information here:

 

http://www.thetradersden.org/forums/showthread.php?p=300188#post300188

 

You may also be able to use XLD to compare the files to the AccurateRip database. I think you need a cue file for this.  

[wgscott]

You can generate a checksum for the actual audio portion of an ALAC file using afhash  (which is part of OS X), followed by the filename,  and you can compare those of two files if the hash is embedded (which you can do with the -w argument):

 

afhash yourfilename.m4a

afhash  -c  youraudiofilename.m4a  yourotheraudiofilename.m4a

 

Quote

AFHASH(1)                 BSD General Commands Manual                AFHASH(1)

NAME
     afhash -- Audio File Hash

SYNOPSIS
     afhash [-h] audiofile1 audiofile2

DESCRIPTION
     Audio File Hash writes an SHA-1 hash to an audio file or prints (to stdout) the hash contained in an
     audio file

OPTIONS
     -h       print help text

     -w       write hash code to audio file

     -x       print hash code from audio file (if present)

     -c       compare hash codes from two audio files

Darwin                         February 13, 2007                        Darwin
Normal Termination

 

 

[Ralf11]

Thx - I'll try those

 

XLD does use the accurip database when it rips

[jin]

 Google' Beyond Compare' free software for mac & win.

[Dan Gravell]

Do you actually want to compare the ALAC bytes, or the decoded bytes?

[Ralf11]

dunno that much about this stuff - I do know that the same bits can be in containers (is that like a containerized cargo cult?)

 

I want to see if iTunes does an adequate job of ripping CDs or something else (like XLD which can use a database on at least some CDs) would be better

 

To test, I chose a beat up CD Song to a Seagull, as Joni is getting pretty old these days.  Recent photos show evidence of bit rot...

[kumakuma]

Simply comparing two ALAC files created with different programs will almost invariability show differences due to the differing compression levels and metadata. 

 

The only way to do this kind of comparison properly is to see if there is any difference between the audio portions after they have been uncompressed to LPCM. The methods that Bill and I described do this.

 

I suggest a two step process:

 

1. Check the XLD log file to see if the CD was ripped properly.

 

There should be a section in this file it saying something like this:

 

Quote

AccurateRip Summary (DiscID: 00077556-0019484a-160d7903)
    Track 01 : OK (v1+v2, confidence 92/164)
    Track 02 : OK (v1+v2, confidence 92/166)
    Track 03 : OK (v1+v2, confidence 91/164)
        ->All tracks accurately ripped.

 

2. If you got an accurate rip using XLD, compare to the files ripped with iTunes to see if the checksums for the uncompressed audio portions of the files match.

 

When it comes to ripping CDs there are only two possible outcomes: the rip is either an identical copy of the CD or it isn't.

[Ralf11]

afhash -c fn1 fn2 returns:

 

No hash in file <filename>

 

the example discussed using the -w switch, so will try that

[Ralf11]

afhash -w fn1 fn2 returns:

 

No hash in file.

SHA1 Hash of audio data : 893e459d254220e7a8aafd4929d8479bd3cb30d8

etc. etc.

 

for both switches I used the Finders drap & drop facility to get the fn's & path on there as arguments

 

BeyondCompare didn't seem to work, perhaps due to the metadata

[kumakuma]

2 minutes ago, Ralf11 said:

afhash -w fn1 fn2 returns:

 

No hash in file.

SHA1 Hash of audio data : 893e459d254220e7a8aafd4929d8479bd3cb30d8

etc. etc.

 

for both switches I used the Finders drap & drop facility to get the fn's & path on there as arguments

 

BeyondCompare didn't seem to work, perhaps due to the metadata

 

I've never used afhash but I'm guessing you can't add a hash to a file and compare in one operation.

 

Try:

 

afhash -w fn1

 

Then:

 

afhash -c fn1 fn2

 

 

 

 

[Ralf11]

Nyet!  same or simiar errors

 

I finally gave up and listened to both sets of song - XLD did not solve all the pops/Snaps/crackles

- unclear if it is any better...

[kumakuma]

17 hours ago, Ralf11 said:

Nyet!  same or simiar errors

 

I finally gave up and listened to both sets of song - XLD did not solve all the pops/Snaps/crackles

- unclear if it is any better...

 

Just close your eyes and pretend you're listening to vinyl. I hear it's what all the cool kids are doing these days.

[wgscott]

I forgot one important thing.  You can write the hash to AIFF but not to ALAC.

 

(I figured out a way to do it if for some reason you want to:  Write the hash to the resource fork.  I wrote a script a few years ago, I think posted on my blog, called "betroth" that does this.  It checksums the audio portion of the files, and stores the checksum in the associated resource fork.  Then you have it periodically examine the file, comparing the extant checksum to that embedded in the resource fork, and it alerts you if a difference is detected.  Such alerts were the first sign I had of a failing external HHD, which I since have replaced with a SSD).

[wgscott]

Here we go:

 

Here is a link to the shell script:

bitrot

[kumakuma]

18 minutes ago, wgscott said:

I forgot one important thing.  You can write the hash to AIFF but not to ALAC.

 

Thanks, Bill. I played with the cmd a little yesterday and got errors when trying to write the hash to various FLAC and ALAC files.

 

BTW, it also works with WAV files so it looks like it's uncompressed data that causes it to chokes.  

[wgscott]

You mean compressed?

[kumakuma]

57 minutes ago, wgscott said:

You mean compressed?

 

Yeah, that's what I meant.

[esldude]

There is a hashtab app and checksum utility app in the mac app store for $1.99 on either.  I haven't used either. 

 

I also thought you could open a terminal window and put MD5 space filename to get an MD5 checksum.  I'll have to try that. 

[esldude]

In the terminal you can use MD5 file name or shasum file name. 

 

iHash is a free app in the Mac app store which is much easier.  You drag and drop the file name, and get a checksum of your choice.  Copy it.  Then try the second file and paste the first one you copied to see if the two match.  If you are only doing a few files it should serve you fine. 

 

Of course this is if the metadata is the same.  

 

For checking audio bits, about as easy to just open one in audacity.  Open the second one and invert.  Then mix and render.  You should come up with all zeroes. 

[jin]

Or try this: http://www.libinst.com/Audio DiffMaker.htm

[wgscott]

11 hours ago, esldude said:

In the terminal you can use MD5 file name or shasum file name. 

 

Why would you want to do this when /usr/bin/afhash does the same thing, but with the audio content only (thus eliminating irrelevant differences in the metadata)?

[esldude]

18 minutes ago, wgscott said:

 

Why would you want to do this when /usr/bin/afhash does the same thing, but with the audio content only (thus eliminating irrelevant differences in the metadata)?

Because some of ralf's entries indicated afhash wasn't working for him. So I offered an alternative with the metadata.

[Ralf11]

Thanks - I tried MD5 alone and with a filename - got nothing.

 

I think I'll close down this experiment and move on to something else.

[esldude]

2 hours ago, Ralf11 said:

Thanks - I tried MD5 alone and with a filename - got nothing.

 

I think I'll close down this experiment and move on to something else.

Try the iHash.  It is a drag and drop graphical way to do it.  If they match fine. 

 

If not, then try Audacity. Could be metadata if they don't match.  Audacity also lets you look at the metadata to see if that is the same or not. 

 

Open one file, then open the second file in the same window. 

Select the second file and under Effects apply Invert. 

 

Then select both tracks and under Tracks select Mix and Render.  If you get a straight line with nothing in it, you have two bit identical files.  Once you have done this it only takes a couple dozen seconds to compare two files. 

 

You also might try Max. 

http://sbooth.org/Max/#max

 

That way you could see if XLD and Max results match that iTunes is the outlier.