Log in

View Full Version : AAC to AC3


manolito
22nd February 2013, 21:49
After some frustration trying to convert large multichannel audio files in the AAC or AC3 format, I decided to write my own small script just for the purpose to convert AAC files to AC3.

My frustration came from the fact that most available audio converters fail when the source file is big enough to result in an intermediate WAVE file which is larger than 4 GB. In this case the WAVE file has to be written in the WAVE_FORMAT_EXTENSIBLE format, and most audio encoders do not support this.

For AC3 to AAC conversions this is no big deal, because BeSweet (I use the BeLight GUI) can do this, it even supports normalizing. AAC to AC3 is a different story, though. BeSweet cannot decode AAC. FFMPEG handles the conversion, but it cannot normalize.

My tool uses FAAD, SoX and Aften, it is a one trick pony, and only the most basic options are supported. If you want to check it out, you can download it here:
https://www.sendspace.com/file/r3x0tz

This is the ReadMe:
AAC2AC3 - Simple audio conversion utility
-------------------------------------------

Converts AAC audio files to AC3 using FAAD, SoX and Aften.
Large multichannel files are supported.

Downmix of multichannel sources to stereo is supported,
output sample rate can be forced to 48 KHz, and
the encoding bitrate can also be specified (CBR only).

Normalizing and resampling are done through SoX
(requires version 14.4.1 or later).

Other effects like DRC profiles or Dialog Normalization
are not supported.



Usage:
Use 'Drag and Drop' or 'Copy and Paste' to feed a source file
to the executable. A target file of the same name and the
extension .ac3 will be created in the source folder.
Temp files will be created in the root folder of the drive
where the source file is located, so make sure that there
is enough free space on this drive.


Known issues:
When converting large files, the Aften progress indicator issues
incorrect numbers. This is purely cosmetic...

The executable is a compiled batch file. If your virus scanner
has a problem with it, file a complaint with the manufacturer...




Cheers
manolito

tebasuna51
23rd February 2013, 12:07
How we can use your aac2ac3.exe if source file, aac2ac3.bat, have this:?

REM You have to edit the following lines!
SET faad=i:\test\faad.exe
SET sox=i:\test\sox.exe
SET aften=i:\test\aften.exe

Maybe you can use the Faad parameter

-b 2

to output 24 bit samples and improve precission.

Bloax
23rd February 2013, 13:07
Shouldn't that technically be "SET faad=%~dp0faad.exe", "SET sox=%~dp0sox.exe" and "SET aften=%~dp0aften.exe"?
That would at least handle the entire "edit this" part of it, because it should define them as being in the same directory as the .bat file.

Which means that the files have to be in the same directory as the .bat file, which is infinitely better than having to change the lines every time you move it around.

manolito
23rd February 2013, 16:37
How we can use your aac2ac3.exe if source file, aac2ac3.bat, have this:?

REM You have to edit the following lines!
SET faad=i:\test\faad.exe
SET sox=i:\test\sox.exe
SET aften=i:\test\aften.exe

Just use the EXE file and tell me if it works...:D

The EXE file is completely self-contained, i.e. all necessary files are embedded. At runtime these files are extracted to a temporary folder and then run from there. The compiler creates a new environment variable called MYFILES which must be used to address the embedded files. So I had to modify the batch script to make it work with the compiler.

Maybe you can use the Faad parameter

-b 2

to output 24 bit samples and improve precission.

This will work (just tested it), but do you really think there will be an audible difference? Especially since the resulting AC3 file will have a bit depth of 16 bit again? (I thought when 16 bits are good enough for LameXP then it will be good enough for me, too).

But of course I can add this to AAC2AC3. Would you prefer this parameter as a selectable option, or should it always be present in your opinion?



@Bloax
Each to his own... On my machine all audio tools are already present in some other folders, and I hate to have the same files on my HDD more than once.

But the bottom line is that you should not use the batch file at all, you should use the EXE file instead. The source script is just there so you can see what I did (or if you want to modify it, of course).



Cheers
manolito

tebasuna51
23rd February 2013, 19:11
... all necessary files are embedded.
OK, I just read the source file.

Especially since the resulting AC3 file will have a bit depth of 16 bit again?
That is not exact, a lossy format don't have bit depth.
The samples aren't stored in time domain but in frequency domain.
And Dolby say than the precission can be equivalent to 20 bit.

manolito
23rd February 2013, 22:07
That is not exact, a lossy format don't have bit depth.
The samples aren't stored in time domain but in frequency domain.
And Dolby say than the precission can be equivalent to 20 bit.


This is what MediaInfo says about the file:
General
Complete name : I:\test.ac3
Format : AC-3
Format/Info : Audio Coding 3
File size : 447 MiB
Duration : 2h 19mn
Overall bit rate mode : Constant
Overall bit rate : 448 Kbps

Audio
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Duration : 2h 19mn
Bit rate mode : Constant
Bit rate : 448 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 447 MiB (100%)

Whatever, so you think I should always set the "-b 2" option? No adverse side effects except a slightly slower speed?


Cheers
manolito

tebasuna51
24th February 2013, 10:50
This is what MediaInfo says...
You don't need believe all that MediaInfo say.

In AC3 metadata don't exist any info about the source from was encoded. In DTS exist a field that say the bit depth of the source but is not always correct, some soft like Surcode put always 24 bit no matter if the source is 16 bits.

Whatever, so you think I should always set the "-b 2" option? No adverse side effects except a slightly slower speed?
The 'pipe' data is transferred by RAM then the speed can be similar.
You can put:
-b X Set output sample format. Valid values for X are:
1: 16 bit PCM data (default).
2: 24 bit PCM data.
3: 32 bit PCM data.
4: 32 bit floating point data.
5: 64 bit floating point data.
but in my test 64 bit float don't work properly.

I think faad work internally with 32 float then need convert the data output, sox must convert also the data to float to normalize and Aften convert also the int data to float.

Then at least 24 int is recommended, similar precission than 32 float.

manolito
25th February 2013, 01:01
Then at least 24 int is recommended, similar precission than 32 float.

Alright, AAC2AC3 now always creates intermediate WAVE files with 24 bit depth.

Updated download link in the first post of this thread...



Cheers
manolito

manolito
5th October 2013, 01:08
Update:

Added option: Output sample rate can be forced to 48 KHz.


Link in the first post of this thread has been updated.



Cheers
manolito

RowaN
14th December 2013, 20:02
I've just converted a MKV to AVCHD and noticed the channel order is wrong. I think its a bug in the old version of eac3to that comes bundled with MultiAVCHD.

So, I tried manually converting the stripped off audio file with a newer version of eac3to. It complained that I'm missing a Nero AAC codec. Seems strange that the old version does not need the codec (when used via MultiAVCHD at least).

So here I am looking for an alternative AAC2AC3 converter and I find this thread. :)

However, I've just tried to convert the audio file (test.mka), and it fails with this error:


Normalize Output ? (Y/N)
Type (Y)es or (N)o ...n

Resample Output to 48 KHz ? (Y/N)
Type (Y)es or (N)o ...n

E:\eac3to\aac2ac3>"C:\Users\Anon\AppData\Local\faad.exe" -b 2 -w "test.mka" |
"C:\Users\Anon\AppData\Local\aften.exe" -b 384 -readtoeof 1 - "E:\eac3to\aac2ac
3\test.ac3"
*********** Ahead Software MPEG-4 AAC Decoder V2.7 ******************

Build: Apr 24 2011
Copyright 2002-2004: Ahead Software AG
http://www.audiocoding.com
Floating point version

Aften: A/52 audio encoder
Version 0.0.8
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License.

**************************************************************************

test.mka file info:
RAW

Error: Bitstream value not allowed by specification
input format: RAW Signed 16-bit little-endian 48000 Hz stereo
output format: 48000 Hz stereo (2/0)

SIMD usage: MMX SSE SSE2 SSE3
Threads: 8

Any help much appreciated. And thanks to manolito for the creation of this program.

Update: I found a solution; used Foobar2000 to convert the .mka (AAC) file to wav (6 channel). Then used eac3to to convert to ac3 (channel order is OK now, having used a newer version of eac3to).

SeeMoreDigital
14th December 2013, 21:15
Update: I found a solution; used Foobar2000 to convert the .mka (AAC) file to wav (6 channel). Then used eac3to to convert to ac3 (channel order is OK now, having used a newer version of eac3to).How about using LoRd_MuldeR's LameXP (http://forum.doom9.org/showthread.php?t=157726) ;)

manolito
15th December 2013, 00:32
@RowaN

test.mka file info:
RAW

Error: Bitstream value not allowed by specification
input format: RAW Signed 16-bit little-endian 48000 Hz stereo
My little tool uses FAAD for decoding. And it looks like FAAD does not support raw AAC files. Sorry, nothing I can do about it...:(


@SeeMoreDigital

Using LameXP might or might not work, because AFAIK it also uses FAAD to decode AAC. I do not have any raw AAC files, so I cannot test it.
And in any case LameXP will not work if the resulting intermediate WAV file is larger than 4 GB. My tool will...:D


Cheers
manolito

RowaN
15th December 2013, 00:35
Thanks guys. Problem sorted as I mentioned so no troubles now.

tebasuna51
15th December 2013, 02:06
My little tool uses FAAD for decoding. And it looks like FAAD does not support raw AAC files. Sorry, nothing I can do about it...:(

faad support .aac files (raw aac with ADTS headers) and .m4a (aac in mp4 container), but not support .mka (audio only in mkv container).

BTW, you can extract the aac file with eac3to:

eac3to test.mka test.aac

and then:

faad -b 2 -w test.aac | aften -b 384 -readtoeof 1 - test.ac3

EpheMeroN
10th January 2014, 03:27
I use Comodo AntiVirus, and when I go to unzip this program to my desktop it auto-quarantines it as a generic trojan TrojWare.Win32.TrojanDropper.Small

manolito
10th January 2014, 03:45
From the first post of this thread:

Known issues:

The executable is a compiled batch file. If your virus scanner
has a problem with it, file a complaint with the manufacturer...

I have included the source batch file in the archive so users can reproduce what the script is doing.



Cheers
manolito

raffriff42
10th January 2014, 04:00
>The executable is a compiled batch file.
If this is open source, source code should include any compiler instructions.

>The EXE file is completely self-contained, i.e. all necessary files are embedded.
This would break license requirements of the called applications, would it not?

Why compile the batch file at all, if the batch file does the same thing?

EDIT
>If your virus scanner has a problem with it, file a complaint with the manufacturer...
EXE contains the string "quick batch file compiler" - this program looks a little sketchy IMHO. How can you know this program's output is virus free?

Not trying to be hostile, Manolito, but you can avoid any misunderstandings by going completely open source. Also, IMHO it is better to provide links to the original author's websites than to embed without permission.

manolito
10th January 2014, 08:38
@raffriff42

You are in a nitpicking mood, aren't you...:p

My distribution contains a "License" folder. It contains a copy of the GPL and the license terms of all used software.
AAC2AC3 by manolito
-------------------------------------------------

The batch script written by me is public domain. You can do with
it whatever you want, no strings attached. No guarantee whatsoever.



Third party software used by my script:

FAAD AAC Decoder:
FAAD is published under the GPL.
Source code available at http://www.audiocoding.com/

SoX Sound eXchange:
SoX is published under the LGPL.
Source code available at http://sox.sourceforge.net/

Aften A/52 Audio Encoder:
Aften is published under the LGPL.
Source code available at http://aften.sourceforge.net/

My batch script is not only Open Source, it is even Public Domain.

The batch file compiler is an older version of Quick Batch File Compiler by Abyssmedia. This is commercial software, but the executables created with this program can be distributed freely. If you think that it contains a virus, just do not use it.

BTW here are the scan results from Jotti:
http://virusscan.jotti.org/de/scanresult/95f0cce4a7da1bbb7fe485836510aa64272f4a87


I strongly believe that my distribution complies with all license requirements. If you disagree, please report it to a mod and try to have my post removed from the forum. Good luck...


Cheers
manolito

DarrellS
21st May 2014, 19:49
Thanks for the program. I tried dBpoweramp and foobar 2000 and neither program would convert my file

SeeMoreDigital
21st May 2014, 19:57
Like I mentioned before: -How about using LoRd_MuldeR's LameXP (http://forum.doom9.org/showthread.php?t=157726) ;)

manolito
21st May 2014, 20:25
After some frustration trying to convert large multichannel audio files in the AAC or AC3 format, I decided to write my own small script just for the purpose to convert AAC files to AC3.

My frustration came from the fact that most available audio converters fail when the source file is big enough to result in an intermediate WAVE file which is larger than 4 GB. In this case the WAVE file has to be written in the WAVE_FORMAT_EXTENSIBLE format, and most audio encoders do not support this.

For AC3 to AAC conversions this is no big deal, because BeSweet (I use the BeLight GUI) can do this, it even supports normalizing. AAC to AC3 is a different story, though. BeSweet cannot decode AAC. FFMPEG handles the conversion, but it cannot normalize.


LameXP is fine as long as the intermediate WAVE file stays smaller than 4 GB. If it gets larger, LameXP will do the conversion without any error messages (so the user thinks all went well), but the resulting target file will be truncated.

I discussed this problem with LoRd_MuldeR extensively, and he decided that the core design of LameXP does not allow to use any dirty workarounds to solve this problem. And this was the reason why I made this little tool for myself, and if others find it useful, all the better...:)


Cheers
manolito

LoRd_MuldeR
22nd May 2014, 20:43
As a matter of fact, the maximum allowable size of a WAVE file is 4 GB. That's because the WAVE/RIFF format uses a 32-Bit field to store the size!

Yes, it's possible to create non-standard, i.e. broken, WAVE files bigger than 4 GB. Such files will obviously contain a nonsense "size" value, because the actual size cannot be stored in a 32-Bit field. And indeed, some decoders will actually output a non-standard WAVE file, when the size grows beyond 4 GB. But other decoders don't and just truncate at the 4 GB boundary - in order to retain a valid WAVE file. It's not in the control of a GUI front-end, such as LameXP, what the particular decoder is going to do! You need to keep in mind that LameXP supports a wide range of input formats and currently uses 18 different decoders to make that possible. Furthermore, even if the particular decoder does create a U]non-standard[/U] WAVE file bigger than 4 GB, there is absolutely no guarantee that the particular encoder will be able to read such a broken file! Some do, some require a special switch, some read only the first 4 GB and some simply reject the invalid file. Again that's not in the control of the GUI front-end. Keep in mind that LameXP supports 10 different encoders by now. And it's not much of a surprise that feeding the encoder with a broken file results in undefined behavior.

Using pipes instead of intermediate WAVE files may seem like slick a solution to get rid of the 4 GB problem - at least at a first glance. But this requires a fundamentally different design of the GUI program. Furthermore, passing PCM data via pipe is anything but trivial! That's because passing the "raw" PCM data is only on thing. But you also need to negotiate the PCM properties, such as the sample format, the number of the channels, the sample rate and so on! And there is no "standard" way of doing this! The most common approach seems to be sending a "fake" WAVE header over the pipe before the actual PCM data. But again this is not supported by all encoders and/or decoders. Heck, many encoders and/or decoders do not even support input/output via pipe at all. Please keep in mind that, unless a method works with all 10 encoders and all 18 decoders, which makes 180(!) combinations overall, it won't be suitable for LameXP. And here we haven't even thought about post-processing filters, such as Normalization or Tone-Adjustment, which LameXP currently applies (optionally) on the intermediate WAVE file. How do we implemented that when we are passing the PCM data via pipe?

Yet another solution, and probably the most "clean" one, would be using WAVE64 files instead of WAVE files. But the non-existent support for the WAVE64 format in most encoders/decoders means that we currently cannot do this either...


If it gets larger, LameXP will do the conversion without any error messages (so the user thinks all went well)

Not quite correct ;)

if(QFileInfo(sourceFile).size() >= 4294967296i64)
{
handleMessage(tr("WARNING: Decoded file size exceeds 4 GB, problems might occur!\n"));
}

manolito
23rd May 2014, 04:59
Not quite correct

Code:
if(QFileInfo(sourceFile).size() >= 4294967296i64)
{
handleMessage(tr("WARNING: Decoded file size exceeds 4 GB, problems might occur!\n"));
}


Sorry, not true at all. Whatever you did to implement this warning, it does not work.

I had done many tests previously, but since you brought it up again, I repeated those tests. Here is a 6-channel AAC source file:
http://www78.zippyshare.com/v/2063751/file.html
http://www78.zippyshare.com/v/97863666/file.html

I used the current stable version 4.09. Converting this 6-ch source file to a 6-ch AC3 file with normalizing does not issue any warning about an intermediate WAV file which is too large, but the resulting AC3 file is borked.

Using the same source file with my AAC to AC3 tool results in a perfect AC3 target file.

In the medical community (this is where I come from) there is an old saying: Whoever heals is right. Now who is right here?


Cheers
manolito

SeeMoreDigital
23rd May 2014, 09:33
Personally speaking, I'm not too bothered about using 'normalizing' options...

But I can confirm that when I dropped your (321MB) 6Ch AAC-LC.m4a file into LameXP 4.10 RC1, I managed to create an 'un-normalized' (447MB) 6Ch 448Kbps AC3 stream. Which plays fine in VLC and MPC and in a couple of my hardware players. It's also accepted by MKVmerge GUI and TSmuxerGUI.

It may not be what you require, but it would be fine for my needs ;)

LoRd_MuldeR
23rd May 2014, 11:56
Sorry, not true at all. Whatever you did to implement this warning, it does not work.

As explained above, LameXP has zero control over what a particular decoder does when the intermediate file exceeds 4 GB. If the decoder decides to create a valid WAVE file and thus to truncate at the 4 GB boundary, then the intermediate file obviously won't exceed a size of 4 GB. And then LameXP obviously won't output a warning about the intermediate file being bigger than 4 GB - since it isn't. Having said that, Valdec (AC3Filter) actually does produce intermediate WAVE files bigger than 4 GB, if you feed it with a very large AC3/DTS source file. And, if such file is encountered, LameXP does output a warning - because it is not known whether the particular encoder will be able to cope with such non-standard (broken) file.

http://i.imgur.com/BK7G1Pys.png (http://i.imgur.com/BK7G1Py.png)

(Screenshot is in German language, but you can believe me that is says "WARNING: Decoded file size exceeds 4 GB, problems might occur!" ^^)


I used the current stable version 4.09. Converting this 6-ch source file to a 6-ch AC3 file with normalizing does not issue any warning about an intermediate WAV file which is too large, but the resulting AC3 file is borked.

Using the same source file with my AAC to AC3 tool results in a perfect AC3 target file.

In the medical community (this is where I come from) there is an old saying: Whoever heals is right. Now who is right here?

I stand right, of course ;)

I never claimed that it would not be possible to perform an AAC to AC3 conversion, even when the intermediate file exceeds a size of 4 GB. In fact, I explained several methods how this can be accomplished, in my previous post (https://forum.doom9.org/showpost.php?p=1681443&postcount=22). In that very same post I also explained why none of these methods is currently/easily applicable to LameXP. Your "AAC to AC3 tool" may work fine for your limited use case. I don't doubt that. But unless your tool supports at least 10 different encoders (like LameXP does), supports at least 18 different decoders (like LameXP does), supports various post-processing filters (like LameXP does) and all the possible combinations work flawlessly, it probably won't be of any help to improve LameXP...

manolito
23rd May 2014, 19:34
I stand corrected about the 'WAVE file too big' warning. It is present in the log, but who reads the log if the program tells you that the conversion was successful?

Here is a proposal which could make us both happy:

Just add SoX to the list where users can enter custom parameters.

This way I could add "--ignore-length" to the SoX command line the same way I already added "-readtoeof 1" to Aften. Maybe the position of this parameter is a problem, because you cannot append it to the end of the parameter list, it has to be at the beginning of the list where the input is defined.

Anyways, this way you would not have to officially support non-standard WAV files, and I could use LameXP to convert large 6-ch AAC files.


Cheers
manolito

Andouille
24th May 2014, 09:27
I know some phones, tablettes or cams output vids with stereo aac but what device produce these 6ch aac ?

manolito
24th May 2014, 20:14
A lot of people like to convert their DVDs or BDs to MP4 with AVC video and AAC audio. And often they like to preserve multichannel audio instead of downmixing to stereo.


Cheers
manolito

Andouille
24th May 2014, 20:31
A lot of people like to convert their DVDs or BDs to MP4 with AVC video and AAC audio. And often they like to preserve multichannel audio instead of downmixing to stereo.


Cheers
manolito

Makes no sense to me.
You are saying that people convert their original dvd 6ch ac3 to lossy aac and then again to a new lossy ac3 encode to enjoy their audio ??

manolito
24th May 2014, 21:02
If you google for 6-ch AAC conversion you will find many folks who obviously have this need. If for example you have such an MP4 file and for some reason you want to create a BD structure from it, then you will have to convert the audio back to AC3 (AAC audio is not BD compliant).


Cheers
manolito

Andouille
27th May 2014, 19:55
If you google for 6-ch AAC conversion you will find many folks who obviously have this need. If for example you have such an MP4 file and for some reason you want to create a BD structure from it, then you will have to convert the audio back to AC3 (AAC audio is not BD compliant).


Cheers
manolito

Ok I googled and what I found is only piracy.
That explains why I did not understand.