Hydrogenaudio Forums

Lossless Audio Compression => Lossless / Other Codecs => Topic started by: Jai Menon on 2008-08-25 07:52:00

Title: LGPL'ed Apple Lossless Encoder released
Post by: Jai Menon on 2008-08-25 07:52:00
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 (http://ffmpeg.mplayerhq.hu/download.html)

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

EDIT : Comparison Chart between various ALAC encoders (http://multimedia.cx/eggs/gsoc-showcase-alac)
Title: LGPL'ed Apple Lossless Encoder released
Post by: Brent on 2008-09-02 11:40:36
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.
Title: LGPL'ed Apple Lossless Encoder released
Post by: Jai Menon on 2008-09-03 06:17:21
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.
Title: LGPL'ed Apple Lossless Encoder released
Post by: Brent on 2008-09-09 23:19:09
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
Title: LGPL'ed Apple Lossless Encoder released
Post by: Jai Menon on 2008-09-11 15:38:12
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.
Title: LGPL'ed Apple Lossless Encoder released
Post by: Brent on 2008-10-12 21:35:29
For anyone interested, I found compiles on a website that can encode alac:

http://tripp.arrozcru.org/ (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?
Title: LGPL'ed Apple Lossless Encoder released
Post by: Jai Menon on 2008-10-20 07:31:50
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 (http://ffmpeg.org/bugreports.html).
Thanks.
Title: LGPL'ed Apple Lossless Encoder released
Post by: xmixahlx on 2008-10-20 08:53:49
will there be a broken-out encoder a la aften for ALAC?


later
Title: LGPL'ed Apple Lossless Encoder released
Post by: Brent on 2008-10-20 22:19:42
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)?
Title: LGPL'ed Apple Lossless Encoder released
Post by: Brent on 2008-11-21 22:21:06
For the record, just tried it with a new build of ffmpeg, 15815, and the problem is still there.
Title: LGPL'ed Apple Lossless Encoder released
Post by: Brent on 2009-01-24 15:34:38
Got the 16537 build from this website:
http://ffmpeg.arrozcru.com/builds/ (http://ffmpeg.arrozcru.com/builds/)

Still length and framecount mismatches...
Title: LGPL'ed Apple Lossless Encoder released
Post by: TechVsLife on 2009-02-04 18:18:45
Got the 16537 build from this website:
http://ffmpeg.arrozcru.com/builds/ (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)?
Title: LGPL'ed Apple Lossless Encoder released
Post by: Brent on 2009-02-07 19:59:02
Just checked with iTunes: it creates ALAC files without mismatches. The problem lies with ffmpeg.
Title: LGPL'ed Apple Lossless Encoder released
Post by: TechVsLife on 2009-02-07 21:38:07
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)?
Title: LGPL'ed Apple Lossless Encoder released
Post by: Brent on 2009-02-08 12:00:10
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.
Title: LGPL'ed Apple Lossless Encoder released
Post by: Justin Ruggles on 2009-03-18 04:12:47
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 (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?
Title: LGPL'ed Apple Lossless Encoder released
Post by: Gregory S. Chudov on 2009-03-19 11:26:26
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.
Title: LGPL'ed Apple Lossless Encoder released
Post by: Justin Ruggles on 2009-03-19 16:34:27
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).
Title: LGPL'ed Apple Lossless Encoder released
Post by: Justin Ruggles on 2009-04-16 04:15:09
The FFmpeg MP4 issue that was causing fb2k to pad the last frame has been fixed in FFmpeg SVN r18504.
Title: LGPL'ed Apple Lossless Encoder released
Post by: nycjv321 on 2009-08-26 05:53:14
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....
Title: LGPL'ed Apple Lossless Encoder released
Post by: nycjv321 on 2009-08-26 16:14:37
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
Title: LGPL'ed Apple Lossless Encoder released
Post by: Gregory S. Chudov on 2009-08-30 23:06:44
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 (http://cuetoolsnet.svn.sourceforge.net/viewvc/cuetoolsnet/CUETools.Codecs.ALAC/).

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
Title: LGPL'ed Apple Lossless Encoder released
Post by: lvqcl on 2009-08-31 15:11:30
CUETools.Codecs.ALAC.dll is 64-bit, and it doesn't work on my 32-bit system (WinXP SP3).
Title: LGPL'ed Apple Lossless Encoder released
Post by: Gregory S. Chudov on 2009-08-31 16:14:41
Thank you, fixed and uploaded new version in the same post above.

Any other test results yet?
Title: LGPL'ed Apple Lossless Encoder released
Post by: nycjv321 on 2009-08-31 20:41:19
I'll check it out later
Title: LGPL'ed Apple Lossless Encoder released
Post by: bbrabant on 2009-09-01 16:02:29
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
Title: LGPL'ed Apple Lossless Encoder released
Post by: Gregory S. Chudov on 2009-09-01 16:30:59
Thanks!
Title: LGPL'ed Apple Lossless Encoder released
Post by: jetpower on 2009-09-15 13:15:06
Also works no problem on my Ipod Nano 4G, even with extreme encoder settings 
Title: LGPL'ed Apple Lossless Encoder released
Post by: prefab on 2009-10-06 16:11:09
Any plans for a 24 bit version ?

cheers
Title: LGPL'ed Apple Lossless Encoder released
Post by: ninekithk on 2009-12-14 07:01:12
Any plans for a 24 bit version ?

cheers


Any updates on can I encode HDCD to 24 bit ALAC using CUETools?

Thanks
Title: LGPL'ed Apple Lossless Encoder released
Post by: Gregory S. Chudov on 2009-12-27 19:12:37
I will try. Does fb2k decode 24-bit files? Don't ask me to install iTunes

For now here's an updated version of the same old 16-bit encoder, it's a bit faster than previous. It beats ffmpeg in both speed and compression.
Title: LGPL'ed Apple Lossless Encoder released
Post by: lvqcl on 2009-12-27 19:52:55
Quote
Does fb2k decode 24-bit files?


No.  And Winamp + Winamp Essentials doesn't decode them too.
Title: LGPL'ed Apple Lossless Encoder released
Post by: prefab on 2009-12-27 21:33:22
Does fb2k decode 24-bit files?
I dont think so. But dBpoweramp Music Converter does. And the version here (http://crazney.net/programs/itunes/alac.html) claims to decode 24-bit files.
cheers
Title: LGPL'ed Apple Lossless Encoder released
Post by: Brent on 2009-12-27 22:13:09
I today checked to see if it's already compatible with lossywav, it sadly isnt. Can someone comment on whether or not this encoder could eventually work with lossywav? Would be a space saver where it's needed most: on my ipod.
Title: LGPL'ed Apple Lossless Encoder released
Post by: Gregory S. Chudov on 2009-12-27 22:24:58
I don't think it could. ALAC format doesn't seem to support wastedbits feature. There's a suspicious wastedbytes field in the packet header, but even if it is what i think it is, it won't be enough.
SimplePortal 1.0.0 RC1 © 2008-2019