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: LGPL'ed Apple Lossless Encoder released (Read 39724 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LGPL'ed Apple Lossless Encoder released

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

LGPL'ed Apple Lossless Encoder released

Reply #1 –
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.

LGPL'ed Apple Lossless Encoder released

Reply #2 –
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.

LGPL'ed Apple Lossless Encoder released

Reply #3 –
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

LGPL'ed Apple Lossless Encoder released

Reply #4 –
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.

LGPL'ed Apple Lossless Encoder released

Reply #5 –
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?

LGPL'ed Apple Lossless Encoder released

Reply #6 –
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.

LGPL'ed Apple Lossless Encoder released

Reply #7 –
will there be a broken-out encoder a la aften for ALAC?


later

LGPL'ed Apple Lossless Encoder released

Reply #8 –
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)?

LGPL'ed Apple Lossless Encoder released

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

LGPL'ed Apple Lossless Encoder released

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

LGPL'ed Apple Lossless Encoder released

Reply #13 –
Quote from: Brent on
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)?

LGPL'ed Apple Lossless Encoder released

Reply #14 –
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.

LGPL'ed Apple Lossless Encoder released

Reply #15 –
Quote from: Brent on
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?

LGPL'ed Apple Lossless Encoder released

Reply #16 –
Quote from: Justin Ruggles on
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.


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.
CUETools 2.1.6

LGPL'ed Apple Lossless Encoder released

Reply #17 –
Quote from: Gregory S. Chudov on
Quote from: Justin Ruggles on
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.


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).

LGPL'ed Apple Lossless Encoder released

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

LGPL'ed Apple Lossless Encoder released

Reply #19 –
Quote from: Justin Ruggles on
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....

LGPL'ed Apple Lossless Encoder released

Reply #20 –
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

LGPL'ed Apple Lossless Encoder released

Reply #21 –
Ported to .NET.

[attachment=5367:CUETools.ALAC.02.rar]

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 2.1.6

LGPL'ed Apple Lossless Encoder released

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

LGPL'ed Apple Lossless Encoder released

Reply #23 –
Thank you, fixed and uploaded new version in the same post above.

Any other test results yet?
CUETools 2.1.6

LGPL'ed Apple Lossless Encoder released

Reply #24 –
I'll check it out later