Skip to main content
Topic: Difference in ALAC bitrates (Read 445 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Difference in ALAC bitrates

I’m new to lossless audio, so please forgive me if I’ve made any mistakes in this post.

To understand which lossless format would be best for me, I downloaded two bundles of three 16-bit 44.1kHz test files (FLAC and ALAC). As I currently use a Mac, I should perhaps choose ALAC, but I’m currently favouring FLAC instead because of its wide availability and support.

Just in case I ever change my mind about formats in the future, though, I thought I’d try converting the FLAC files to ALAC to put my mind at ease; using FLACTunes from the App Store, this was extremely straightforward. But I noticed something unusual: the bitrate of the downloaded ALAC files differed slightly from those that had been converted from FLAC to ALAC:

File one
Original ALAC file: 413kbps
Converted FLAC to ALAC file: 415kbps

File two
Original ALAC file: 501kbps
Converted FLAC to ALAC file: 502kbps

(File three matched perfectly.)

Just to eliminate the possibility of an iTunes error, I used the Mac Terminal, which confirmed that the bitrates shown in iTunes had been correct. I also tried converting the FLACs with Max, but the result was (understandably) the same.

I just wondered if anyone might be able to explain the discrepancy and what I’m misunderstanding, please?

Thank you in advance.

Re: Difference in ALAC bitrates

Reply #1
There are an infinite number of possible bitrates that any file can have, so unless you use exactly the same settings and encoder, you are unlikely to get exactly the same bitrate.  It will probably be close, but not exactly the same.

Re: Difference in ALAC bitrates

Reply #2
To add: with ALAC and WMAL, it isn't so transparent to the user that such things could happen under the hood. With FLAC, on the other hand, there are nine compression levels that have a shorthand switch and then quite some others.

But: will foobar2000 with foo_bitcompare work on Mac? If so, there is a utility to compare before and after bit by bit, and the user does not need to worry over "did I do something wrong here?!?".

(Unfortunately, ALAC-in-MP4 is not a checksummed format, so you cannot compare those.)
Memento: this is Hydrogenaudio. Do not assume good faith.

Re: Difference in ALAC bitrates

Reply #3
I don't know much about ALAC but it's lossless so I wouldn't worry too much about it (unless you are concerned with file size).

As you probably know, FLAC has 9 compression settings with 0 being the fastest that produces the largest files (least compression = highest bitrate) and 8 being the slowest producing the smallest files (most compression = lowest bitrate).

I assume there are similar variations/compromises in ALAC settings or algorithms.

Re: Difference in ALAC bitrates

Reply #4
My knowledge of the ALAC format is small, and I don't have any apple hardware but I want to say several things:

- There are several ALAC encoders: The official one from Apple, and several reverse-engineered ones from third parties.
- The website from FLACTunes does not mention what it uses to convert between the formats, but being a Mac OS application it might be using CoreAudio, which in turn should mean that it uses the Apple encoder. I haven't found information for or against this, other than recently it added support for AAC, which might also come from CoreAudio.
- You don't mention where you got the test reference files, so we don't know what could have been used to generate those files.
- From what I remember, ALAC was a weaker format compared to FLAC (i.e. it cannot compress as much as the latter), at least as implemented by Apple.

Finally, the differences you mention are quite small. Depending on the size of that testfile, it could even be some padding on the tags or similar.

Re: Difference in ALAC bitrates

Reply #5
- From what I remember, ALAC was a weaker format compared to FLAC (i.e. it cannot compress as much as the latter), at least as implemented by Apple.

Performance is less of an issue these days with storage turning cheap, but if you use battery-powered devices, then CPU load could still affect battery life?
But assuming you actually care about performance - and not about having an Apple-supported format per se - then ALAC is weaker than FLAC on absolutely every yardstick I can think of. From the most recent comparison the wiki links to: http://www.audiograaf.nl/losslesstest/Lossless%20audio%20codec%20comparison%20-%20revision%204.pdf
* The initial tables say that FLAC encodes / decodes CDDA material 2-5 times as fast as ALAC. At given encoding speed, ALACs are two to five percent larger. There is no "at given decoding speed", as FLAC -8 decodes 2.5 times the fastest ALAC. (Again, maybe relevant for battery-powered devices. Or if you do frequent transcodings on slow hardware?)
* Note, this is with a checksumming disabled on FLAC. Which makes a fair comparison to ALAC, which has no such feature. When I started ripping, I was unaware how essential that feature is. FLAC enables it by default, do not turn it off.

Not in that comparison is:
* MP4 tagging (atoms) are quite a beast. While Vorbis (and Ape) tags can be criticized over free-form lack of standardization, MP4s have all those issues and then some. You can get your MP4 files delivered with a lot of proprietary tags, some designed to be invisible and just invade your privacy - IDK if iTunes still does that. (fb2k can "sanitize" tags though.)
* You need to "do something" if you want to identify content from filenames. Even if you use ".m4a" for audio-only, thus distinguishing between video and audio, you will have the same for AAC in MP4. Of course you can name every ALAC as ".alac.m4a"; MS-Windows will not distinguish out that as a separate file type, IDK about Apple's OS'es.

(There are some more quirks to ALAC's disadvantage in the comparison, that are not essential to a tl;dr version for those who listen to CD rips. Like, no "wasted bits" feature and sucks at mono-encoded-as-stereo - whoever needs lossless for audiobooks on their cellphones ...)



Finally, the differences you mention are quite small. Depending on the size of that testfile, it could even be some padding on the tags or similar.
If it were FLAC, a good application should know what is audio and what is padding. If it is as easy in an MP4 container ... dunno.
Memento: this is Hydrogenaudio. Do not assume good faith.

 
SimplePortal 1.0.0 RC1 © 2008-2018