Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Verifying quality of converted FLAC/ALAC/AIFF files (Read 11688 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Verifying quality of converted FLAC/ALAC/AIFF files

Hi all,

I'm currently converting all my FLACS to ALAC having recently switched to Mac.  (Still have a BootCamp partition though to do all the conversion in XP.)

I started this process on my Mac but realised that the converter I was using tend to drop samples at the end - not good.  So I decided to do this whole process in XP instead.

My workflow looks like this:

1. Converting FLAC files to AIFF using dBpoweramp (sometimes I have 24-bit/48 kHz files and therefore I prefer using iTunes ALAC codec - dBpoweramp's ALAC codec only supports 16-bit/44.1 kHz).

2. Transfer AIFF files to iTunes and use iTunes' ALAC encoder to convert to ALAC.

3. Use foobar's Bit Compare component to compare the original FLACs with the iTunes ALAC versions.

Now, since I have foobar with the "Bit Compare" and "Verify Integrity" components installed - have a couple of questions on these:

(1) Will the bit compare component "spot" any clicks or pops (if any) in the conversion process - i.e. will any "distorted" ALACs show us defective?

(2) What is the difference between "Verify Integrity" and "Bit Compare" in this instance?


Many thanks in advance!

Nubben

Verifying quality of converted FLAC/ALAC/AIFF files

Reply #1 –
Bit compare is exactly what it says it is. It compares both decoded audio files bit for bit (probably byte by byte or word by word). And it can not only notify you that "file A is different from file B" but it also detects offset shifts and counts different samples. So if the offset is the same but there's a damaged sample it will tell you that "1 sample is different at position xxxx".

Verify integretiy does different things but it can be useful for finding errors, too. It can check for checksum mismatches. Some codecs allow storing a checksum of the decoded or encoded audio. Verify integrity can check these. But it's main purpose is to check for decoding errors. Damage to an audio file can but not necessarily must (in case of WAV for example) have an effect on decoding, in most cases there will be an decoding error tho, for codecs compressed codecs there will.

As to what would be the most efficient and error-safe method for converting... I don't know. If your hardware is ok, and the encoders/decoders all honor the specifications then nothing should go wrong. But be aware that tags are more likely to get lost, than the actual audio information. Also I wouldn't recommend foobar2000 for CD rips with embedded cue sheets because it will cut off the track one pregap. But for converting tagless (w/o cue sheet) audio files foobar2000 is probably the weapon of choice, since it supports multi-core CPUs.

Verifying quality of converted FLAC/ALAC/AIFF files

Reply #2 –
In addition to what Fandango said,

1)  The bitcompare tool decodes the files using the decoders in foobar and compares the decoded PCM streams. It is reliable. A "click" or any other difference in the decoded PCM data would not pass the test.

However, it cannot possibly confirm that some other decoder would output identical PCM data. I'm not saying that any differences would be likely, but to be absolutely sure you would need to convert the ALAC files to wave or AIFF on your Mac and compare these decompressed files with the original source files.


2) The verify tool checks if the file works correctly in foobar. It decodes the files and it may verify a checksum if the file format supports that and a checksum is included in the file headers. Regarding ALAC, I doubt it does anything else than decodes the files and reports if that didn't work flawlessly -- like when the reported length is inaccurate, which seems to happen with dBpoweramp encoded ALAC files. (I don't know if this is caused by foobar's ALAC decoder or if only dBpoweramp encoded ALAC files produce this minor problem or if the ALAC format simply does not provide sample accurate duration info.)

Verifying quality of converted FLAC/ALAC/AIFF files

Reply #3 –
Quote
I started this process on my Mac but realised that the converter I was using tend to drop samples at the end - not good. So I decided to do this whole process in XP instead.

I forgot to ask about this. What converter did you use? Did you try Max from www.sbooth.org?

If a conversion tool would work correctly on your Mac you could do only the bitcomparison part with foobar.

Verifying quality of converted FLAC/ALAC/AIFF files

Reply #4 –
Fandango/Alex B:  Many thanks for both your replies! 

I understand the true purpose of these foobar tools now.  A couple of follow-up questions if ok.

Fandango: Re integrity verification and the checksums.  In the info box shown in foobar after the verification of the ALAC files only the "Status" column shows "OK" the rest is either "N/A" or "#" (the #-sign is for the CRC I think).  That means some of the tags (re CRC for instance) has been lost between the FLAC and ALAC conversion, right?

Also, is foobar good at breaking out cue + cd image files into individual FLAC files?  In the beginning I was using EAC and creating one file + cue sheet and need to convert those as well.  Will foobar handle the pregaps differently here as well, i.e. converting already existing image + cue files?

Alex B: When you say "However, it cannot possibly confirm that some other decoder would output identical PCM data." Does that mean there would be audible differences (in your view) between foobar and iTunes?  One can get too paranoid I guess.  As long as I have an iTunes-made ALAC file that comes out as identical as the original FLAC then I'm fine.  (I don't even think there is a bit comparison tool for the Mac.)  I'm not too fussed about the subsequent ALAC to MP3s converted files being identical - as long as I have a "pure" copy of the lossless file that's acceptable.  And, I use iTunes on the Mac anyways.

Thanks a lot both of you for your earlier replies - much appreciated!

Nubben

Verifying quality of converted FLAC/ALAC/AIFF files

Reply #5 –
Quote from: Alex B on
Quote
I started this process on my Mac but realised that the converter I was using tend to drop samples at the end - not good. So I decided to do this whole process in XP instead.

I forgot to ask about this. What converter did you use? Did you try Max from www.sbooth.org?

If a conversion tool would work correctly on your Mac you could do only the bitcomparison part with foobar.



Alex - thanks again.

I did use Max on the Mac and that decoder/encoder is the problem for me - sometimes it has thrown out inconsistent ALAC files from the FLACs.

I only recently stumbled across this bit comparison thing as my encoder of choice (dBpoweramp) has a (at the present stage) defective AIFF encoder.  That encoder was dropping samples towards the end of each track.  Spoon (the developer) has since issued a beta of the new AIFF encoder which will hopefully address this issue.

But, out of curiosity I did a check of my backed up FLAC files to see if the ALACs made from those had dropped samples too.  I thought although these ALACs had been converted using Max in Mac OS X maybe they had the same problem?  So I took some FLACs and converted those into ALACs using Max.  And, as you might have guessed, these FLACs had errors - more specifically dropped samples towards the end.  Same problem as the dBpa AIFF encoder.

Thanks again for your reply!

Nubben

Verifying quality of converted FLAC/ALAC/AIFF files

Reply #6 –
Quote from: Nubben on
(I don't even think there is a bit comparison tool for the Mac.)


You can use shntool cmp from the command line or in the shntool tab of xACT. Use XLD for conversions.

Verifying quality of converted FLAC/ALAC/AIFF files

Reply #7 –
Quote from: Nubben on
Fandango: Re integrity verification and the checksums.  In the info box shown in foobar after the verification of the ALAC files only the "Status" column shows "OK" the rest is either "N/A" or "#" (the #-sign is for the CRC I think).  That means some of the tags (re CRC for instance) has been lost between the FLAC and ALAC conversion, right?

No, the integrity check has nothing to do with tags. They're ignored. When we were talking about checksums we didn't mean checksums for the whole files, but only for the audio stream within the file. If you're uncertain what I mean, you should read this article: http://en.wikipedia.org/wiki/Container_format_(digital) So the MD5 check is for the audio stream only, and headers/tags are ignored.

Quote from: Nubben on
Also, is foobar good at breaking out cue + cd image files into individual FLAC files?  In the beginning I was using EAC and creating one file + cue sheet and need to convert those as well.  Will foobar handle the pregaps differently here as well, i.e. converting already existing image + cue files?

No it won't. The individual files should be identical to EAC's. But fb2k can't create "proper" non-compliant cue sheets. So it will be a one-way conversion. The information about the pregap positions are lost anyway in the audio files, that's why you would need a non-compliant cue sheet in the first place for 1:1 CD copy. Nevertheless the audio of the pregaps gets appended to the previous track, it just makes the previous track a little bit longer at the end and the current track a little bit shorter at the beginning. So the audio in the pregap is not lost, only the information where the pregap once was.

If you want to convert your multi-track rips (one audio file for the whole CD) into a "proper" EAC-like multiple WAV rip, you should check out CUE Tools. It can batch convert the single-file cue sheet to non-compliant cue sheets only. No need to convert the audio with CUE Tools also. You can do the audio part with fb2k. And BTW, there's also a DOS batch script around here that can do this, converting cue sheets without doing the audio part.

Anyway CUE Tools can do the cue sheet part, but can't do the ALAC nor AIFF part. fb2k can't do the cue sheet part but can do the AIFF part, can't encode to ALAC.

PS: IMHO the pregap position information isn't that relevant. If you only want lossless quality audio and are not interested in reconstructing the original CD with its fancy gap countdown abilities on an old school CD player... then converting the cue sheets is useless extra work. Convert to AIFF with fb2k and you'll be fine, you can even try to max out your harddisk I/O throughput by using multiple decoder threads in fb2k. Then convert the AIFFs to ALAC on your Mac.

Verifying quality of converted FLAC/ALAC/AIFF files

Reply #8 –
Thanks for your reply.  I'm only interested in converting existing image files using the cue sheets to divide the image into individual tracks.  The resulta would be WAV or AIFF and then I would convert those files to ALAC in iTunes.

So, if I understand you correctly - foobar WILL CORRECTLY split an image file into separate tracks and while doing so add the pre-gap at the end of the previous track.  This set-up is what I want anyways so if it does that then great.

Many thanks!

Moderation: Removed unnecessary and confusing botched quotation.

Verifying quality of converted FLAC/ALAC/AIFF files

Reply #9 –
Quote from: Nubben on
...while doing so add the pre-gap at the end of the previous track.

While doing so it will preserve the audio data that was flagged as a pregap at the end of the previous track.

Now if there was a hidden track in the 00 index before the first track (HTOA), it will be lost.

Verifying quality of converted FLAC/ALAC/AIFF files

Reply #10 –
Quote from: Nubben on
1. Converting FLAC files to AIFF using dBpoweramp (sometimes I have 24-bit/48 kHz files and therefore I prefer using iTunes ALAC codec - dBpoweramp's ALAC codec only supports 16-bit/44.1 kHz).

2. Transfer AIFF files to iTunes and use iTunes' ALAC encoder to convert to ALAC.


Just out of curiosity; why are you adding this extra step?  You can go straight from FLAC to ALAC using dBpowerAMP.  There is no need to go from FLAC to AIFF and then to ALAC.

Verifying quality of converted FLAC/ALAC/AIFF files

Reply #11 –
You quoted the reason:

Quote from: Nubben on
I have 24-bit/48 kHz files and therefore I prefer using iTunes ALAC codec - dBpoweramp's ALAC codec only supports 16-bit/44.1 kHz

Verifying quality of converted FLAC/ALAC/AIFF files

Reply #12 –
Quote from: kornchild2002 on
Quote from: Nubben on
1. Converting FLAC files to AIFF using dBpoweramp (sometimes I have 24-bit/48 kHz files and therefore I prefer using iTunes ALAC codec - dBpoweramp's ALAC codec only supports 16-bit/44.1 kHz).

2. Transfer AIFF files to iTunes and use iTunes' ALAC encoder to convert to ALAC.


Just out of curiosity; why are you adding this extra step?  You can go straight from FLAC to ALAC using dBpowerAMP.  There is no need to go from FLAC to AIFF and then to ALAC.


dBpa's ALAC only supports 16-bit that's why.  I have also heard about compatibility issues with dBpa's ALAC files and iTunes.  Don't know if this is true but don't want to risk anything.

Verifying quality of converted FLAC/ALAC/AIFF files

Reply #13 –
Quote
I have also heard about compatibility issues with dBpa's ALAC files and iTunes.


We have never had issues with iTunes, just an older version with an Apple TV which was set to stream (and needed ID Tags in certain positions). All has been fixed for the last year atleast.

Verifying quality of converted FLAC/ALAC/AIFF files

Reply #14 –
Quote from: spoon on
Quote
I have also heard about compatibility issues with dBpa's ALAC files and iTunes.


We have never had issues with iTunes, just an older version with an Apple TV which was set to stream (and needed ID Tags in certain positions). All has been fixed for the last year atleast.


Sorry Spoon - my bad then.  Btw, I use dBpa for all my ripping anyways.

Any chance of supporting 24-bit/48khz in the near future?

Many thanks.

Verifying quality of converted FLAC/ALAC/AIFF files

Reply #16 –
Quote from: Alex B on
Regarding ALAC, I doubt it does anything else than decodes the files and reports if that didn't work flawlessly -- like when the reported length is inaccurate, which seems to happen with dBpoweramp encoded ALAC files. (I don't know if this is caused by foobar's ALAC decoder or if only dBpoweramp encoded ALAC files produce this minor problem or if the ALAC format simply does not provide sample accurate duration info.)


Is anything more known about this? I'm observing this with dbpa r14 two years after your post. The foobar2000 bit comparator says the FLAC originals and ALAC converted files compare the same, but the verifier reports variable, tiny length errors for every single ALAC file. However, converting the dbpa ALAC files in Easy CDDA Extractor to ALAC results in files that all verify OK. Again, the decoded data all compares the same, and I don't know if these length discrepancies really matter, but it's annoying nonetheless when trying to troubleshoot problems with Apple stuff, because it's one more thing to rule out.

Verifying quality of converted FLAC/ALAC/AIFF files

Reply #17 –
As others have said just use XLD

Verifying quality of converted FLAC/ALAC/AIFF files

Reply #18 –
Don't have a Mac.

The funny thing is that EZCDDA creates ALAC files that iTunes reports as 1411 Kbps. Again, probably doesn't matter, but annoying nevertheless. I guess to get "perfect" files, you need to convert to ALAC using a 3rd party tool, import into a "dummy library" in iTunes, have iTunes convert the ALAC files to ALAC, rename the iTunes output with Mp3tag or something, and then add those files to your real library. (Converting to ALAC in iTunes fixes the dbpa glitch and presumably the EZCDDA glitch, too.) Fun fun fun.

Verifying quality of converted FLAC/ALAC/AIFF files

Reply #19 –
By using bit-comparison, you will just know whether a file was different from the other, bit-by-bit. It will never know where the pops and clicks had happened throughout the track, well if pops ever influenced those bits, you'll know because of the difference but still, you will never know where it is.
sin(α) = v sound/v object = Mach No.