Since 20th August, the open source multimedia framework FFmpeg has support for the Apple Lossless format in the form of a native encoder for the very popular, cross platform libavcodec. The encoder provides compression comparable to iTunes and files are also known to work on the iPod.

You can check it out by grabbing a recent Subversion checkout from :
http://ffmpeg.mplayerhq.hu/download.html

News item based on : http://ffmpeg.mplayerhq.hu/index.html

EDIT : Comparison Chart between various ALAC encoders

Interesting. How stable is the encoder? I remember that dbPowerAmp had some problems during it development and some files were incompatible with iTunes and iPods. Does ffmpeg have this too, or is that a matter of more testing and bugfixing?

Perhaps this encoder can be altered to work in cooperation with LossyWav. Mobile players like the iPod are one of the most interesting uses for LossyWav imho.

I haven't seen any problems in my tests, and the files play perfectly on the iPod according to reports. But please do report bugs if you find any. As for LossyWAV support, further RE'ing is required to find out how the iTunes/iPod decoder handles lower order bits. I'll definitely look into it.

As I couldn't find any binaries to play with, I downloaded the source code (ffmpeg-export-snapshot.tar.bz2) but I'm actually not sure how to compile this (on Windows). I've found a few howto's, but they're all dated and use strange custom arguments that seem to enable only specific funtionality, while I'd like to compile an as complete as possible build.

Can someone help me with this, or put his own compiled binary online (that can encode to ALAC)? Thanks.

btw, once I have a binary, I can use the following, right?
ffmpeg -i input.wav -acodec alac output.m4a

Well, you'll need the latest msys and probably the updates for bash, coreutils and gnu make 3.81. Also, you'll need the mingw port (current stable should be fine). Once you configure these and have a working tool chain and msys environment, a simple './configure --enable-memalign-hack && make' should work. This is the bare minimum. If you need external library support like x264, libfaac etc, use the corresponding configure switches.

BTW, The commandline you mentioned for alac encoding is correct.

Thanks.

For anyone interested, I found compiles on a website that can encode alac:

http://tripp.arrozcru.org/

Couldn't get it to compile myself, and I guess I'm not the only one

BTW, I'm getting length mismatches in foobar bitcompare. Jai, can you comment on this?

Could you upload the sample to upload.mplayerhq.hu/Mplayer/incoming? I'll see what can be done. More info on reporting bugs here: http://ffmpeg.org/bugreports.html.
Thanks.

will there be a broken-out encoder a la aften for ALAC?


later

I tried to upload but I'm getting cd errors and write errors: my client can't change the directory nor create files on your ftp server.

The length and framecount mismatch occurs with every file I've tried though. So, if you're not experiencing this behaviour, it has something to do with the build I used (from that website I mentioned)?

For the record, just tried it with a new build of ffmpeg, 15815, and the problem is still there.

Got the 16537 build from this website:
http://ffmpeg.arrozcru.com/builds/

Still length and framecount mismatches...

I assume you're not getting mismatches with other encoder tools (iTunes to alac, or dbpoweramp to alac)?

Just checked with iTunes: it creates ALAC files without mismatches. The problem lies with ffmpeg.

Thanks for confirming that. Anyone know whether the problem in the ffmpeg code has been found (& is it on the list to be fixed soon)?

I sent a message once to the mailinglist, but I don't think it ever appeared on it. I also havnt seen any chatter about this problem, so I guess its under the radar for the devs. Also, Jai hasnt been to hydrogen for quite some time, so I don't really know how to get the attention of one of the devs.

Jai asked that you file a bug report, which I have not seen. That can be done at http://roundup.ffmpeg.org.

At any rate, it appears that the problem is in the final frame. The fb2k ALAC decoder pads the last frame with zeros, even though the number of samples in the last frame is encoded in the frame header. The dBpoweramp decoder (and the iTunes decoder IIRC) do not pad the last frame. I have not examined why ALAC files generated with other encoders do not give mismatches in fb2k, but I have a suspicion that they write the total number of samples in the mp4 container somewhere and fb2k uses that to truncate the last frame instead of using the frame header. Since ALAC has no specification, and the iTunes decoder handles the FFmpeg-generated files properly, I would consider this an issue with fb2k, not FFmpeg. That said, it would still be nice to figure out the exact issue and try to match the iTunes encoder output if possible.

edit: I did test dBpoweramp, but I don't have iTunes anymore... could you convert the ALAC file to WAV in iTunes and compare that to the original WAV using fb2k bitcompare?

There are two places in mp4 container, where the length is stored.

First place is in moov.mvhd chunk (movie header).
iTunes encoder writes the approximate number of samples there.
ffmpeg encoder writes the approximate length in milliseconds.
This is not very reliable field and is ignored by fb2k.

Second place is moov.trak.mdia.minf.stbl.stts (sample table).
This is where iTunes encoder stores the correct length. This is what fb2k uses.
This table contains array of struct { int sample_count; int sample_duration }
Total length is a sum of sample_count*sample_duration.
Normally for iTunes-encoded file this table contains two entries.
First entry with sample_duration=4096 and sample_count=total_samples/4096
Second entry with sample_duration=total_samples%4096 and sample_count=1
For ffmpeg, this table sadly contains only one entry, so the total sample length is rounded up to a multiple of 4096.

Thanks Gregory. I will run this by the FFmpeg mov/mp4 maintainer. Still I wonder why foobar reverts to rounding up when it could use the encoded sample count in the frame header of the last ALAC frame. But the mp4 needs to be correct either way, and hopefully this will be fixed in the next FFmpeg release (likely to be in 3 to 6 months).

The FFmpeg MP4 issue that was causing fb2k to pad the last frame has been fixed in FFmpeg SVN r18504.

I am using a windows build, revision number 18639 im still getting the frame padding issue....

I must add that the file does seem to be lossless though, I did a md5 hash sum comparison with one song (flac source) and they matched... may test more but md5sums matching usually aren't a coincidence... if only ffmpeg (like flac), or foobar added a md5 hash as a tag though

Ported to .NET.

Click to view attachment

I'm not an iPod person, so cannot test if produced files play on the device.

Source code is here.

Please test it.

UPD: fixed an error, the output file had wrong extension (flac instead of m4a).
UPD2: replaced 64-bit version with any-CPU version

CUETools.Codecs.ALAC.dll is 64-bit, and it doesn't work on my 32-bit system (WinXP SP3).

Thank you, fixed and uploaded new version in the same post above.

Any other test results yet?

I'll check it out later

Tested with default settings. A 787 MB wave compressed to 371 MB. Played without trouble in foobar2000 ALAC decoder 1.0.3.
Converted with foobar the m4a to wave. The hash of the resulting wave is the same as the original wave.

Hope this info is useful.

Greetings,

Ben

Thanks!

Also works no problem on my Ipod Nano 4G, even with extreme encoder settings

Any plans for a 24 bit version ?

cheers