Some time ago, when making a DVD out of some footage, I came to realize that although we have some pretty great free solutions for DVD compliant stereo encoding (PCM WAV and MP2 via TooLAME) there isn't a widely adopted free solution for multichannel (AC3 or DTS) encoding. Why is that the case? Are AC3 and DTS inherently more complicated than, say, LAME or Vorbis? Maybe there's some sort of legal monkeywrench? Or is there just not enough interest in those formats?

There is a free LGPL AC3 encoder. It is part of FFmpeg. A while ago, I used the code from FFmpeg and added some additional features to create a standalone commandline encoder. It isn't very well tested at the moment and probably will only work on Linux x86, which is the only platform I have tested it on. I haven't tested multi-channel encoding either, but it should work in theory.

I have a website for it if anyone is interested.
http://jbr.homelinux.org/aften/
(note: this is on a new server, so if there are problems with the link just let me know and I'll move it)

AC3 is not really too complicated as compared to other audio codecs. The specification is also very thorough and pretty easy to understand. The only legal issue I know of has to do with Dolby's trademark of the AC3 name.

-Justin

Oh, I know about ffmpeg's AC3 encoder, but all reports I read about it said it wasn't too good. Does your modification include other changes aside from the implementation of standalone encoding?

The FFMPEG encoder is very basic (following the F.Bellard tradition) , but might be a very valuable starting point. (and it's integer only, so it could be very interesting on some platforms)
In my opinion, it could be very interesting to create a cooperative project (like on sourceforge) around your command-line version.

I think that to attract potential developpers, you should have an interesting project and some basic tools. You already have the interesting project.
Regarding tools, some good basic ones would be:
*a command line interface (already done) to ease experimentation with the encoder
*a library structure could be a good "selling" point
*a way to conveniently analyse the encoding choices

Regarding this last point, some output regarding thresholds and bit allocation into a text file that could be further displayed using Gnuplot could do the trick. (it should be way faster than to write a graphical frontend in Gtk...)

With those points, your project could have a good starting. (although we never know)

It would be great to see a project arise from this .

But it might not be that difficult to revert back for those that are interested...

You're right that the FFMpeg AC3 encoder is very simple. I have added a few things, but there could be a lot more done (e.g. add channel coupling, better exponent strategy selection).


A library structure and a better build system are probably the next step. The reason I converted to floating-point from fixed-point was because the stereo rematrixing was generating high-frequency noise with fixed-point due to the inaccuracy. I could easily make it a compile-time option and leave out the stereo rematrixing in the fixed-point version.

I have done some experimenting with Gnuplot output, so that wouldn't be too difficult.

Thanks for the encouragement.
-Justin

Main reason that there is no "free" DTS-encoder is that there is no spec
available afaik, unlike AC3, where something can be found in the ATSC docs
(bitstream syntax etc.).
Both companies are earning money via license fees/royalities, so they are for sure
not interested in supporting anything "free". Obviously, they can't do very much
against a de-/encoder written from scratch from a document open to the
public...

Hi,
Thanks to some improvements posted on the doom9 forum, I have done some work on Aften today and released a new version.

http://jbr.homelinux.org/aften/aften-0.01.tar.bz2

• simple configure script
• piped input and output
• corrected 6-channel mapping
• corrected defaults for mix levels
• commandline options
• quiet mode (no console output)
• per-frame or average statistics
• big-endian support (not tested though)

Here is the output from "aften -h"


-Justin

On your Aften page the current version is 0.02, and the links go to different files as well. So what package to download?

I've compiled it under VC++ 8.
Only minor changes needed to make it compile (like there's seem to be no <inttypes.h> in MSC)

I've compressed some 44.1kHz/Stereo/16bit wav files.

Looks like Foobar2000 (0.8.3) doesn't like the output of Aften - it refuses to play the resultant file.

Media Player Classic (6.4.9.0) playes CBR correctly while it chokes on VBR (it tries to play it though).

I'm off to try other playback options...

BeSweet had no problem decoding VBR.

I've successfully ABX-ed (12/12) the CBR 256kbit mode (-b 256000).
I think the agressive lowpass (~14 kHz) made it easy.

Does anyone know at what bitrates should a 2ch AC3 achieve transparency?
I've seen DVDs use 192kbit so I assume it should be somewhere in that ballpark.

I don't think the time has yet come to ABX this new encoder. It might take a while until it's on par with commercial solutions.

Sorry...I got overly ambitious and decided to add a few more commandline options, so I made a 0.02 version. I didn't mean to confuse things. From now on I'll keep the 0.02 version there and add another link for aften-current.tar.bz2 which will always reflect the newest development version.

-Justin

Thank you for the great feedback! I will add inttypes.h emulation soon. As I am not running a Windows machine, I pretty much only have access to 1 decoder, liba52, which handles VBR just fine. Your information is very interesting, as I can't find anywhere in the specification where it says all frames in a stream must be the same size. I was worried more about hardware compatibility, but it seems there are indeed some software issues out there. I think I will maybe add a big warning when trying to encode in VBR mode. I am glad BeSweet gets it right. Maybe it uses liba52 or some derivative of it?

As a response to the ABX-related post, maybe I should have warned that the quality pretty much sucks as compared to other modern codecs or even full-spec AC-3 implementations. I'm more concerned with compatibility and adding specification features at this point. There is a long way to go. I don't have the best ears for quality right now, but I have noticed CBR starts getting noticeably worse below 192kbps. With VBR it pushes it a little lower, maybe 160 or so. But none of this is objective, so it doesn't matter much. I do need to work on the cutoff frequency. I was maybe a little too aggressive with lowering the bandwidth rather than letting the bitrate increase and/or SNR (the "quality" param) decrease. I just need to do some objective tests to tweak the settings...or enable users to adjust them more!

I am pretty new to audio encoding. Lossless sure is much easier to test... I need to look more into improving my listening skills and do some practice listening tests. Any help will with testing will be very much appreciated!

Thanks!
-Justin

Ok for the inttypes I made a new header file (I called it common.h):
I made sure I call this header early enough in each *.c file.

I also found a bug which caused the program to crash in release (optimized) mode.
In dsp.c in the function mdct512 the end loop should be
instead of

As for audio encoding I'm not experienced in it either - but that won't stop me

I don't know much about these things, but I think I found what you're talking about. [link]

Actually not enough, since only the frame headers are described there...rest is considered
DTS confidential. Anyway, thanks for the link. :-)

After reading AC3 sources I have to say - this is quite a strange format.
Unlike MP3, AAC, DTS and others Dolby tried to put the psy model in the decoder

I think that computing power from MDCT is not correct, because a representation of a signal is phase dependent with MDCT. That's why psy models use FFT instead.

Unfortunately the quantatization of the individual critical bands cannot be coded - it's computed from the exponent values. The only idea that I have is boosting the exponents in the bands with power loss to force higher relative masking treshold - but I'm not sure if it can be done so it results in a coding gain.

The less trivial stuff is to adjust the following (hardcoded) values:


Btw, I used -b 192000 -w 38 and so it has a 16.1kHz cutoff which I like much better than the variable bandwidth setting. It's not without artifacts but it sounds promising so maybe some tweaking can help.
I've tried -s 1 (block switching) but it caused more artifacts so I think it needs some tuning before it can be useful.

@Justin : what is the difference between aften & aften_g ?

"aften_g" is compiled with debugging symbols. The "g" refers to the gcc option "-g". This makes debugging easier (gdb will give the file, function, and line number of an error), but the binary is larger. The "aften" binary is the same as "aften_g", but the debugging symbols are stripped so the file is smaller.

-Justin

Justin Ruggles> I couldn't find a binary on your web page. Is it because of U.S. patent legislative? If it is a problem to provide a binary, I think you might ask rjamorim to host it at rarewares.org.

And one more question: Is it easy to integrate your changes back to FFMPEG? Many other projects use FFMPEG as a base for AC3 encoding. FFDShow or QuEnc for example. Or can these projects easily switch to Aften?

Anyway thank you for this encoder. Now I can encode from whatever format directly to AC3 in foobar2000 or BeHappy. I hope BeLight will be updated soon to support Aften. Are you working on it kurtnoise?

I'll be creating my own DVD next week and I'll use Aften for AC3 encoding (unfortunately only 2.0 stereo). I'll let you know some feedback then.

Some binaries for win32 OS can be found here...


Concerning Aften with BeLight. Yes, I'll try asap.

It's not because of patents. I really haven't heard about specific patents related to AC3. The specification hints that there might be some, but doesn't say who/what/where like other specifications do. So unless I get some nasty letter from Dolby or someone else I am just going with what I've got. AFAIK the only legal issues are trademarks owned by Dolby, but I do not claim Aften to be Dolby Digital or Dolby Surround compliant. In fact, I might even put a warning in the README file that Aften is not a licensed Dolby product, and therefore any content created with Aften should not be labeled as "Dolby Digital" or "Dolby Surround". I am probably already protected by the LGPL license from the actions of the program's users, but it couldn't hurt.

Back to the point, the reason for no binary is basically because I don't use Windows and haven't really had the time to setup a working Mingw cross-compiler/Wine testing environment. If I get really brave (or really desparate) I might get a 2nd hard drive and start using Win2k again for testing purposes. I guess I could provide Linux static binaries. I might do that if Sourceforge approves the project to be hosted there. It's a good thing kurtnoise is doing a fabulous job of releasing binaries about as quickly as I make changes.


Some things yes, some no. They would probably accept the changes if I made it support either fixed-point or floating point. Right now the main benefit of Aften over FFmpeg is in the fact that it is a standalone AC3 encoder, and that it supports VBR, variable bandwidth, and stereo rematrixing. If I add enough good features I might be able to port the ones which will work in fixed-point mode back into FFmpeg.


Great! Maybe I'll have DRC implemented by then...if I'm not too exhausted. I'm going through inventory at work this week. Today was the first day...12 hours of going up-and-down ladders counting stuff! I'm too tired to think.

-Justin

Would it be a good idea to organize a listening test to compare aften to current commercial solutions?

good idea.
i did few test comparing results in my amplifier from Aften and soft encode.
(was not a ABX test,i'm still learning to use)
sounds equal and Aften is faster.

Here is an update.

Aften version 0.04 has been released.
It is available at the new Sourceforge page for Aften

The source is now managed by SVN, which is hosted by Sourceforge.
svn co https://svn.sourceforge.net/svnroot/aften aften

Also, there are daily builds hosted on my personal web space.

There is an aften-devel mailing list for any who are interested in the development side of Aften.

Notable changes in 0.04:

• separate library and commandline frontend
• input filters (LFE, DC, bandwidth)

Note that the current SVN version encodes about 20-30% faster than 0.04. After a few more significant changes and a more robust build system, I will probably jump up to release 0.10.

Thanks,
Justin

Nice! It seems that you are going into the right direction, setting up everything needed for a potential development community.

Shouldn't you add a link the the blog within the Aften home page?

Gabriel, would there be a way to include some of the tweaks made to LAME over the years into Aften?

Do you mean including a psy model into Aften? Of course it is possible, and even a simple (but correct) one could greatly improve results.
However, not the one included in Lame, as mp3 and ac3 have different block sizes.

I'm trying to do it right from the beginning, but it's a bit overwhelming for me at the moment though. I'm used to spending more time on coding and less time on maintenance & discussion. I just have to get into the flow of it I think.


Yes. The link has been added. Really, the whole page really needs revamping though.



One drawback with AC3 is that the bit allocation is tightly bound to the format. Only basic parameters are included in the bitstream, and the decoding is absolutely dependent on feeding those parameters and the mdct coefficient exponents to the predefined bit allocation routine. There is much room for improvement in modifying the basic bit allocation params to values other than default, but this still doesn't allow for a whole lot of control. There are several other areas which could be improved, such as different block switching and rematrixing (m/s) algorithms. Also, I am currently working on a better exponent strategy selection. Channel coupling has not been included at all yet.

All these things do employ psy model principles, but the bulk of the algorithm cannot be separated from the format as it can be in mp3 or vorbis. Unless I'm just missing something here...

I'm currently reading the Bosi book, and while I did not reached the AC3 section yet, she effectively mentionned several times that a part of the psychoacoustis processing/model is also part of the decoder, unlike other coding schemes.
I'll have a better opinion when I'll read the AC3 section.

I don't know, I read many things about encoder differences like block length, subband or transform-based encoding and psymodels and have little idea what they mean (I'll search for their definitions, I promise) but was wondering if any of those which have been used on LAME, Vorbis aoTuV or FAAC could be grafted into Aften. It's good to hear that using different psymodels could be possible.

I've done a little more reading on this subject, and although most of the psy model in AC3 is pre-defined (it actually has a bit-exact definition), I think a 2nd-layer psy model could maybe be used to generate some of the parameters which are passed into the spec psy model and for other parts of the encoding. For example, the m/s encoding can benefit from knowing the masking threshold. Exponent strategy choice can benefit from some form of tonality calculation. Also, I've seen one paper that says the "fast gain" parameter corresponds to signal-to-mask ratio. I am pretty much brand new to psychoacoustics, so I've still got a steep learning curve.



Some of the same concepts and code could probably be used. I would have to make those portions conditional on the configuration though and separate them from the rest of the code due to licensing. Aften is LGPL, but LAME and FAAC are GPL. aoTuV is under the Xiph license, but I doubt I could base the Aften psy model on aoTuV alone.

-Justin

Then I'd suggest you to read Bosi's book. Zwicker's one is still the reference, but for an introduction Bosi's book is very good.


Lame is LGPL.
Anyway, you are very unlikely to be able to copy portions of psymodel code from another encoder. You are more likely to use ideas from others that would need to be rewritten for your specific needs.

They look like great reads, but will put a hole in my wallet. I'm sure it's worth it though. Thanks for the suggestions.


Oops. Sorry about that.

Dear all,
I has one question about "aften" channels.
In the program, the A52_MAX_CHANNELS is defined by 7.
Why not "6" (5.1 channels) ?

Thanks a lot!!
Best Regards

Thanks for noticing that. It's a left-over from when I tried to implement channel coupling. The 7th channel would be the coupling channel. I'll change it to 6 until I attempt coupling again...

-Justin

For a good amount of time already, the free AC3 encoder "Aften" is being discussed and developed in the doom9 forum, binaries and development builds available from kurtnoise and wisodev. Version 0.0.6 just added Dynamic Range Compression with presets, and is constantly being extended.

@ Roberto Amorim & Co.: Do you think it would be a win for RareWares to add it to the "Others" page?

How is the quality for Aften compared to say, ac3enc (the one in BeSweet)?

As far as I know, Aften is better, but not by a whole lot. BeSweet's ac3enc is straight from FFmpeg. Aften is also based on FFmpeg, but has had active development to improve speed and quality over the past year. The quality difference is not much at this point, but the speed is. Things will definitely change soon though, as there are some good quality improvements coming in the near future. The work is pretty much done, but the merging and releasing will take a month or two probably.

Since this is HA, I'll qualify my post by saying that I have done no ABX testing between the two encoders, but will take an educated guess that there would not be a statistical difference at this point. I have actually been holding off on posting updates and new releases here until I get the audio quality up-to-scratch (psych model and channel coupling).

when the next update on Aften?

Are you sure? I downloaded a DTS specification years ago from ETSI.org. If I remember correctly it was a document with over 100 pages and contained everything you need for a baseline en-/decoder (no DTS-HD, though). It certainly contained more than just a description for the frame headers.

At least there's libdca (open source library) for decoding DTS. (I was under the impression the authors used the ETSI spec to write their decoder.)

Cheers!
SG

Hi there.
As it happens I'm currently very interested in this topic because I'm evaluating the possibilities to encode to multichannel formats for an opensource project that will be part of an audio production toolchain.
It should, at the final stage, be able to write an encoded file to disk that could then be used together with video material or alone.

Since it's aimed at professional use we'd like to support industry standards, but from what I found out today there are few options.

aften/ffmpeg seems to be about it. I have so far not found any opensource software that can encode dts or any newer version of ac-3 or dts.

Is there something I've missed?
Is something in development?
Are there non-proprietary alternatives?

there is a dts encoder that it's under construction from FFmpeg crew (formely dcaenc) but not far usuable yet...

Hi Sebastian,
no, wasn't shure :-)
Actually you are right, there is a Doc on ETSI, which I just downloaded. Not as nice for coding as the ATSC-spec for AC3, but still quite exhaustive, including pseudocode and tons of tables.
Of course nothing about the HD version(s), as you wrote already.
Cheers