DivX AAC Encoder Beta 1

[DigitAl56K]

http://labs.divx.com/files/icon_tk_aac.pngDivX Plus adds the capability for high quality surround sound audio to the DivX ecosystem using Advanced Audio Coding (AAC) technology. To support the creation of AAC tracks for DivX Plus HD content we've created a command-line AAC audio encoder.

Visit DivX Labs (http://labs.divx.com/node/11682) to get the download and find more information about Beta 1.

Complementing this encoder, we're also jointly releasing an updated beta H.264 encoder today, check out the thread in the MPEG-4 AVC / H.264 (http://forum.doom9.org/showthread.php?p=1313720#post1313720) forum.

[microchip8]

Will there be a Linux version of it, like Nero's neroAacEnc, or does DivX still live in Windows land only and thinks there's nothing else out there? :p

[DigitAl56K]

Hi froggy1,

There may be a Linux version in future. Currently we are in the beta phase and development will continue on the Windows platform in the short term. However, we are aware of Linux and Mac also, and you'll be pleased to know that we do actually build certain projects for Linux already internally :)

You can help us prioritize ports to other OS's by letting us know where you would like to see the AAC encoder used and any additional features you think would be helpful to support those uses. For example, do you just want to use it standalone? Would you like to write a UI for it? Are there existing projects you think might be interested in using it?

Although the tools we're creating will support Windows first we want to provide better support overall in the long term so please do send us your ideas. Posting here, PM, or email to amayo (at) divxcorp [dotcom] are all good ways.

[SeeMoreDigital]

Well I'm very surprised...

I thought I'd never live to see the day when DivX would provide support for AAC audio encoding... What made you guys change your mind?

[microchip8]

Well, it'll be nice to have a stand-alone binary for Linux. When Nero ported its neroAacEnc encoder to Linux, a lot of Linux people liked this and it got attention from them, mostly due to it offering superior quality than existing encoders and being also natively available for Linux which eliminates the need for intermediate apps like Wine to run it on Linux. It does not need to be open source and I'm sure people who write encoding GUIs for Linux (like selur with his sx264) will add support for it. I'll also add support for it to my scripts which get used quite a lot too by many people. Personally, I do not write GUIs for encoding as I don't find them that much useful since they do nothing for ~95% of the encoding job and most of them are too cluttered, IMHO, and of course, on Linux one can highly script things easily ;)

About the features, I still have to go through it and see what it can do, so right now I can't really make any suggestions or requests except for the above Linux one ;)

[DigitAl56K]

I thought I'd never live to see the day when DivX would provide support for AAC audio encoding... What made you guys change your mind?

Schizophrenia.

Just kidding ;) We've had support for AAC encoding in DivX Converter and playback in DivX Player and DirectShow (as part of an MKV file) since the release of DivX 7, so our support for AAC isn't new.

@froggy1 I'm also interested in whether you're primarily doing audio encoding or also using AAC for video files?

[microchip8]

@froggy1 I'm also interested in whether you're primarily doing audio encoding or also using AAC for video files?

I do both. My full music collection is encoded to AAC (using nero's encoder) and I fully 100% have switched over in using H.264 video + AAC audio (HE-AACv1) in MKV for my movie encodings. I prefer AAC over any other lossy audio codec ;)

[juGGaKNot]

i use -q 8, is it better than nero aac -q 5 ?

aac lc

btw h264 looking great

btw

AVC-H264 import - frame size 1184 x 664 at 50.000 FPS
Import results: 616 samples - Slices: 31 I 187 P 398 B - 616 SEI - 31 IDR
Stream uses B-slice references - max frame delay 2
Unknown input file type
Error importing C:\x264divx\Movie_2D\T1\movie.m4a: End Of Stream / File

Encoding started at 02:55 PM and finished at 03:01 PM

Press any key to continue . . .

divx h264 and aac

[DigitAl56K]

i use -q 8, is it better than nero aac -q 5 ?

You tell me! ;)

The error message you are seeing from MP4Box is odd, is it because you have named the file extension .m4a rather than .aac? The encoder is outputting an ADTS-encapsulated stream.

[microchip8]

@DigitAl56K

I've not yet had time to test it today but I would want to ask this. If a Linux version is made available somewhere in the future, it would be nice to add a -ignorelength option (like in neroAacEnc) which is useful when encoding through a pipe ;)

[DigitAl56K]

@froggy1:

Regarding -ignorelength, which tools are passing a WAV structure via pipe?

[microchip8]

@froggy1:

Regarding -ignorelength, which tools are passing a WAV structure via pipe?

MPlayer can output to WAV file and one can use a (named) pipe to pass the output of MPlayer to neroAacEnc, for example...

mkfifo audio.wav

neroAacEnc -br 55000 -he -ignorelength -if audio.wav -of audio.m4a &
mplayer inputfile.avi -really-quiet -nocache -vo null -vc null -ao pcm:fast:file=audio.wav

[DigitAl56K]

I guess in this particular case you assume the writing application doesn't add any additional information after the data chunk.

That's interesting, I'll keep it in mind for Linux.

[microchip8]

I don't think MPlayer does that and also I use this method in both h264enc, xvidenc and divxenc and it has never failed me once. -ignorelength basically tells the nero encoder to ignore the length signaled by WAV headers of the input. It's useful for apps outputting to stdin.

[tebasuna51]

Regarding -ignorelength, which tools are passing a WAV structure via pipe?

All AviSynth based decoders (MeGUI, BeHappy, Bepipe, Wavi, SoundOut).

Tools like Sox.

Decoders like Faad

Foobar2000

...

[DigitAl56K]

At least some of these tools are passing raw PCM via pipe and passing sample rate, channel configuration, and bit depth via command-line arguments, which is what I expect to be more common. We're already considering adding support for this.

[tebasuna51]

...We're already considering adding support for this.
Reasons:

1) Support for wav's > 4GB.
Multichannels movie audiotracks can have a equivalent wav file with invalid header. RiffLength and DataLength can't be greater (four bytes) than 2^32

2) Support for unknow source parameters.
We can't construct a command line before read the source file, or the source is also piped by other app.

3) Other encoders support the -ignorelength (or equivalent) parameter:
Aften, NeroAacEnc, OggEnc, Flac.

[DigitAl56K]

The encoder should already support WAV files larger than 4GB (from file).

On #2 and #3, it is true you would need to know the properties of the source file, but I see BeHappy is already doing this for Ogg, and CT AAC.

We will consider also supporting WAV, though PCM may arrive first.

[tebasuna51]

... but I see BeHappy is already doing this for Ogg
Yeah, i was waiting until vorbis-tools 1.3.0 (changelog ... * oggenc: --ignorelength; support for Wave files > 4 GB (#1326)) was official.

[roozhou]

The encoder should already support WAV files larger than 4GB (from file).

On #2 and #3, it is true you would need to know the properties of the source file, but I see BeHappy is already doing this for Ogg, and CT AAC.

We will consider also supporting WAV, though PCM may arrive first.

Is that so difficult to support WAV? You just need to parse the 44byte wav header to get channels and bitdepth. After that you ignore anything else and treat the rest as raw PCM. It could be done within 10 lines of C/C++ codes.

[DigitAl56K]

@roozhou: Of course we support WAV from file already, we just need to make sure the functionality works correctly when it's modified for reading from stdin.

Others: Is the encoder working well for you? :)

[roozhou]

@roozhou: Of course we support WAV from file already, we just need to make sure the functionality works correctly when it's modified for reading from stdin.

Others: Is the encoder working well for you? :)

Yes, it works. But the result sounds bad, worse than any modern encoders including NeroAacEnc, iTune, CT aac, Aotuv and even LAME.

[DigitAl56K]

Can you give the command lines you are comparing? Also, can you share the source file?

[roozhou]

LC aac:
-v 4 -i input.wav -o output.aac -f 16000
HE aac:
-b 96 input -o output.aac -f 16000 -e 1
nero:
-q 0.39
CT AAC(from winamp):
bitrate = 128kbps
lame:
-V6
aotuv:
-q 2

Sample was found on hydrogenaudio forum. This is a killer sample:
http://www.hydrogenaudio.org/forums/index.php?act=attach&type=post&id=4983

[hajj_3]

will the final version be free? will there be a 64bit version? will it be multithreaded? how will the audio quality compare to nero's AAC codec and ogg codec? How will the encode speed be compared to nero's aac codec? will it work with all standalones that can play aac?

[roozhou]

will the final version be free? will there be a 64bit version? will it be multithreaded? how will the audio quality compare to nero's AAC codec and ogg codec? How will the encode speed be compared to nero's aac codec? will it work with all standalones that can play aac?

AFAIK the stream produced by beta 1 has no compatibility issue but is far away from ogg vorbis and far far away from neroAac in quality.

[CruNcher]

AFAIK the stream produced by beta 1 has no compatibility issue but is far away from ogg vorbis and far far away from neroAac in quality.

Hehe not really surprising seeing how much R&D Nero put in the Audio part of this buying top Engineers for it :)
Mainconcept is more into Video then Audio :D and for sure they're some Psy Generations behind here.

[Midzuki]

Apologies for being late :o , but anyway,
here goes my humble suggestion:

DigitAl56K wrote:
The encoder should already support WAV files larger than 4GB (from file).

...

We will consider also supporting WAV, though PCM may arrive first.

Supporting .W64 input would save us all from a lot of possible headaches. :)

[IgorC]

AFAIK the stream produced by beta 1 has no compatibility issue but is far away from ogg vorbis and far far away from neroAac in quality.

It's very premature to make such conclusion based on very fast comparison on only one sample and without previous experience of audio listening test.

In fact I find Divx is comparable to CT and Nero AAC encoders.

Public listening test is to be prepared http://www.hydrogenaudio.org/forums/index.php?showtopic=77272