AC3 to AAC conversion

[Loomes]

detmek, as you can see from my posts im trying to fully understand the background here.

If you encode 32kbs mp3 with 32kbs aac you will make audio with even worse quality

why? how is this exactly explained? besides, one can still decide if saved space is worth the additional loss of quality.

AAC encoder needs over 256kbs to preserve transparency

...everyone is telling something different here. reading the internet it ranges from 96 to 256 kbps when it comes to aac transparency.

With 640kbs 5.1 AC3 you could save some space by re-encoding into AAC with 256-320kbs

sure, but why exactly do you suggest 256-320 kbps for 5.1 aac? as you can see from my previous post i am still trying to get a grip on the 5.1/kbps thing.

[filler56789]

Originally Posted by Loomes

but why exactly do you suggest 256-320 kbps for 5.1 aac?

For AAC, the "perceptual transparency" happens 'somewhere' between 48kbps and 64kbps per (full-range) channel. In other words, a 2.0 AAC stream requires between 96kbps and 128kbps. For 5 (full-range) audio channels, the equivalent values will be: between 240kbps and 320kbps.

However I myself do not believe very-much in those "recommended" values. I prefer to re-encode 2.0 sources to CBR AAC at 160, 176 or 192 kbps, just to be on the safe side

[detmek]

1. Every time you try to re-encode something, keeping or changing format, it gets decompressed into PCM. So, encoder does not have info about what previous encoder did.

MP3, AAC, Vorbis ect are perceptual coders. It means encoder will run audio date through psychoacoustics model to remove sounds that are masked by other sounds. The lower target bitrate - more aggresivly psy model will remove sounds. Low quality audio has a lot of artifacts but psy model can not distinct between artifacts and real details in audio. So, it may remove real data and leave artifact.

2. Transparency is individual. One may not discern encoded audio from the source at 96kbs for stereo but someone else may do that for much higher bitrate like 160kbs. A lot of people agree that 96-128kbs AAC stereo bitrate is a low threshold for transparency. It may be lower or higher for you but you need to do some ABX tests. If 96-128kbs is some sort of threshold for stereo 256-320kbs would be threshold for 5.1 surround. Again, it is individual and that is why everyone is telling you different numbers.

3. The best way would probably be to use quality settings and not a bitrate. Find what quality number gives you transparent audio, maybe rise it one step up just to be sure and use it for every audio encoding job, no matter if it is stereo or surround audio. Lower complexity audio will get less average bitrate and higher complexity audio will get more average bitrate.

@filler56789
AAC encoders usually do not have true CBR mode. And CBR is the worse mode to use. Low complexity parts of the same audio are encoded at the same bitrate as high complexity parts which is not good, ie, if you use 192kbs CBR you will encode pure silence with same bitrate as some very complex part with lots of clear different sounds. The point is - bitrate is no measure of quality. We just use some generalization to expain something in more simpler way.

[filler56789]

Originally Posted by detmek

@filler56789
AAC encoders usually do not have true CBR mode.

AFAIK, there are zero AAC encoders which support true CBR mode. Even enc_aacplus cannot do that.

And CBR is the worse mode to use. Low complexity parts of the same audio are encoded at the same bitrate as high complexity parts which is not good, ie, if you use 192kbs CBR you will encode pure silence with same bitrate as some very complex part with lots of clear different sounds.

I know. But I don't care, because "storage space" is not a problem for me. What really matters is, AAC is better (or sucks less) than MP3. And I don't use AAC for multichannel stuff — both AC3 and DTS still are more adequate for this task, IMHO.

[kuchikirukia]

Originally Posted by detmek

Encoding 384kbs 5.1 AC3 does not make much sense if you want to keep 5.1 sound, even if you use AAC encoder al even AAC encoder needs over 256kbs to preserve transparency. With 640kbs 5.1 AC3 you could save some space by re-encoding into AAC with 256-320kbs.

I'd agree. Going from 384kbps 5.1 AC3 to ~280kbps AAC is only going to be a file size savings of 4.6% with 2Mbps video. 4.3% if there's a 128k 2ch track with it. It's not worth any more loss in quality.

[hello_hello]

Originally Posted by filler56789

AFAIK, there are zero AAC encoders which support true CBR mode. Even enc_aacplus cannot do that.

I know. But I don't care, because "storage space" is not a problem for me. What really matters is, AAC is better (or sucks less) than MP3. And I don't use AAC for multichannel stuff — both AC3 and DTS still are more adequate for this task, IMHO.

I don't get the "limit the bitrate" part though. The last stereo track of a TV show I encoded with Nero Q.50 was 157kbps average and 204kbps maximum. The last stereo movie soundtrack was 186kbps/234kbps. I'm a little confused as to how, at least in theory, a CBR 190kbps encode of either of those examples wouldn't result in a higher bitrate and lower quality.

I can see why the second one resulted in a high average bitrate. While playing it in foobar2000 and watching the bitrate go up and down it surprised me how high it was at times when it sounded like it was encoding a whole bunch of not much (I haven't paid attention to that sort of thing previously). I guess maybe sometimes there's not much info to throw away. At one stage the bitrate hovered around 195kbps for about 30 seconds during which time there was nothing but footsteps and a background noise sounding like wind.

What's the logic behind AAC not being as adequate for multi-channel?

Originally Posted by Loomes

why? how is this exactly explained? besides, one can still decide if saved space is worth the additional loss of quality.

Lossy encoders such as AC3/AAC/MP3 etc throw information away. The idea is not to remove anything you can hear, but every time you re-encode more information is lost. Probably going from one format to another would increase the loss a tad, as each format compresses differently.

You could think of the VBR quality setting you choose as the quality relative to the original. The lower the quality setting, the bigger the difference. If you re-encode the original, then re-encode the encode, then re-encode the second encode etc..... sooner or later you'll hear the audio deteriorate even if you use the same quality setting each time. I'd assume the lower the quality setting, the quicker you'll hear it.

[filler56789]

Originally Posted by hello_hello

I'm a little confused as to how, at least in theory, a CBR 190kbps encode of either of those examples wouldn't result in a higher bitrate and lower quality.

I didn't say that it wouldn't (result in a higher bitrate and lower quality). But I forgot to say that I don't care about this 'detail'

What's the logic behind AAC not being as adequate for multi-channel?

Possibly not a matter of logic, but surely it's a "feature" that I cannot be fond of:

http://forum.videohelp.com/threads/3...=1#post2158472

[tebasuna51]

Originally Posted by hello_hello

How does 2 pass mode make sense for VBR encoding and is it actually possible?...

The eac3to parameter -2pass is related to eac3to decoder (gaps/overlaps/normalize) and is not a encoder option for NeroAacEnc.

[Motenai Yoda]

use qaac in cvbr mode (vbr with predictable size) at 96~128kbps for 2.0 sources and at 208~256 for 5.1 sources (qaac with tvbr 63 give approximately these range depending on source quality/complexity)

also qaac can work in abr and cbr mode too. https://github.com/nu774/qaac/wiki/E...-configuration

[hello_hello]

Originally Posted by tebasuna51

The eac3to parameter -2pass is related to eac3to decoder (gaps/overlaps/normalize) and is not a encoder option for NeroAacEnc.

Doesn't eac3to do all that anyway? If it finds gaps etc it just does it and I'd assume normalising implies a second pass. I do recall "detected clipping, second pass" messages.

It has a -no2ndpass parameter but I couldn't see -2pass in the list of command line options. Maybe I've missed it. It still doesn't make sense in combination with VBR encoding to me though, and NeroAAC definitely has a -2pass option. I could get it working for ABR encoding but not for VBR however I didn't try using a command line directly, just foobar2000.

[hello_hello]

Originally Posted by filler56789

Possibly not a matter of logic, but surely it's a "feature" that I cannot be fond of:

http://forum.videohelp.com/threads/3...=1#post2158472

To be honest I'm not quite sure I understand the problem.

When you decode audio it should be decoded using the wave file channel mapping, that's fed to the encoder and it remaps it as required. AAC uses the same channel mapping as DTS by default (at least for 5.1ch). I think in the early days of AAC encoding there were some mapping issues with specific encoders/GUIs, and I kind of remember an issue with Ogg, but I can't remember why. As far as I know it's all a thing of the past. I've never had an issue with AAC channel mapping myself.

I haven't checked every combination thoroughly but the information offered in the post you linked to seems to be correct according to QAAC. If you look at the pics of the command prompt windows in this post you'll see the default channel order list as displayed by QAAC and in the second pic you'll see it's showing (for 5.1ch audio) the input using wave file channel mapping and the output having standard AAC channel mapping, and all is as it's supposed to be.

It's nothing unique to AAC. DTS and AC3 use different channel mappings by default and you can specify explicit channel mapping. Chances are many of the encoders most of us use have a method of specifying the input channel mapping (the Aften AC3 encoder does), but I'm not sure about specifying a different channel mapping for encoding. I'm not sure why there'd be much need to fiddle with that anyway.

There's a list of audio channel mappings for the common formats at the bottom of this page:
http://avisynth.nl/index.php/GetChannel
Another list here:
http://en.wikipedia.org/wiki/Surroun...identification

[filler56789]

Originally Posted by hello_hello

To be honest I'm not quite sure I understand the problem.

Surely you haven't understood the problem. I am not talking about channel *mapping*, I'm talking about (properly-flagged) channel *layouts*. I still see no good-reason why AAC does not (or should not) support 2.1, 3.1 or 4.1, for example.

https://github.com/nu774/qaac/wiki/M...nnel--handling

P.S.: https://www2.iis.fraunhofer.de/AAC/multichannel.html — at the bottom of the page

[Loomes]

Originally Posted by hello_hello

Doesn't eac3to do all that anyway? If it finds gaps etc it just does it and I'd assume normalising implies a second pass. I do recall "detected clipping, second pass" messages.

Thats correct, -normalize in eac3to forces a second pass as well as detected clipping.

Originally Posted by hello_hello

It has a -no2ndpass parameter but I couldn't see -2pass in the list of command line options. Maybe I've missed it.

The -2pass parameter in eac3to (I'm using latest Version 3.29) does definitely exist. I just tested it with an ac3 by doing "eac3to.exe my.ac3 my.wav" without getting a second pass and then I did "eac3to.exe my.ac3 my.wav -2pass" and had a 2 pass.

Originally Posted by hello_hello

It still doesn't make sense in combination with VBR encoding to me though, and NeroAAC definitely has a -2pass option. I could get it working for ABR encoding but not for VBR however I didn't try using a command line directly, just foobar2000.

Why doesnt it make sense, technically? As I understand 2 pass does great improvement in quality by analyzing first before processing. NeroAAC has a 2nd pass, as well as h264 which is also a VBR process in a way, roughly said. Another question is: Does qaac have a 2pass option? In foobar2000, you can give "Additional command-line encoder paths" in "Preferences: Advanced" config which I have set to C:\sfx\qaac\" but I am not sure if it accepts command line parameters for the encoder somehow.

[detmek]

2pass in NeroAAC encoder does not make any sense because it is used with quality mode, not bitrate mode. x264 has 2nd pass, but only when you use bitrate mode. In bitrate mode encoder has limited bits that must properly alocate for maximum quality. In quality mode encoder is not limited by bitrate and can use bits as much as it needs for requested quality.

QAAC does not have 2-pass mode because Apple AAC encoder does not have 2-pass mode.

[hello_hello]

Originally Posted by filler56789

Surely you haven't understood the problem. I am not talking about channel *mapping*, I'm talking about (properly-flagged) channel *layouts*. I still see no good-reason why AAC does not (or should not) support 2.1, 3.1 or 4.1, for example.

I thought it did, it's just that none of the encoders we use have bothered with channel layouts that are obsolete or nobody will use. I'm not even sure if I can recall any discreet 2.1/3.1/4.1ch audio in the wild. Do you actually have a need to encode it?

8.5.3.2 Explicit channel mapping using a program_config_element()

Any possible channel configuration can be specified using a program_config_element().There are 16 available PCE’s, and each one can specify a distinct program that is present in the raw data stream.

Not that I have any 2.1/3.1/4.1ch audio, but I created some for testing and I've at least managed one proof of concept sample. Some encoders spat out all the non-supported formats. Some took (for example) 4.1ch audio and converted the LFE to a centre channel. That's assuming my assumption of what would constitute 4.1ch audio is correct (front stereo, rear stereo and LFE) otherwise maybe it's not the encoder's fault, but it'd be better to refuse to encode it rather than only appear to encode it correctly.

NeroAAC is quite 2.1ch friendly though. That's the one exception so far. For the other formats it outputs them using the default layouts, but for 2.1ch it was co-operative. Unless my concept of 2.1ch is wrong....

[Loomes]

Based on the discussion here I conclude that its best to do AC3 to AAC conversion the following way:

eac3to "myTrack.ac3" "myTrack.wav" -normalize
qaac64 "myTrack.wav" --ignorelength --no-delay --tvbr 73 --quality 2

I did tests with 3 different headphones (Monster Turbine (in ear), V-Moda Remix Remote, (in ear), Sony MDR-V 700) on iPad Mini and Desktop PC via Asus Xonar D1 soundcard. I was trying --tvbr 63 first but results seemed to sound rather tinny to me and voices a bit thinner in some cases. So I switched to 73 and cant tell a difference from original AC3 anymore. I said earlier that I was pleased with --tvbr 63 but that was because I was testing with rather shitty headphones, I think. Here are some results (info coming from MediaInfo):

640kbps 48KHz 5.1 Channel AC3 of 276 MB -->
369kbps 48KHz 5.1 Channel AAC of 127 MB (58:55)

640kbps 48KHz 5.1 Channel AC3 of 249 MB -->
338kbps 48KHz 5.1 Channel AAC of 132 MB (53:03)

384kbps 48KHz 5.1 Channel AC3 of 129 MB -->
317kbps 48KHz 5.1 Channel AAC of 107 MB (45:44)

192kbps 48KHz 2.0 Channel AC3 of 82 MB -->
115kbps 48KHz 2.0 Channel AAC of 50 MB (58:13)

As stated by some users before, conversion of 384 (or lower) AC3 does not make much sense but I am using a Synology NAS and its official App "DS-Video" does only allow download of Videos on end-devices which consist of H.264 Video and AAC sound, for whatever reason. Download before watching can be very useful when WLAN traffic is high or NAS is serving too many clients. Filesize savings for 640kbps AC3 are quite nice. More than 100MB per 60min episode means 1 GB for 10 episodes without any (noticeable) quality loss in sound.

[hello_hello]

Originally Posted by Loomes

The -2pass parameter in eac3to (I'm using latest Version 3.29) does definitely exist. I just tested it with an ac3 by doing "eac3to.exe my.ac3 my.wav" without getting a second pass and then I did "eac3to.exe my.ac3 my.wav -2pass" and had a 2 pass.

Yeah it's working that way for me too, which has me wondering as to the point of it again. I just tried it using AC3 for the input and flac as the output. It created the wave file first, then the flac file, but there must be more of a point to -2pass than simply creating a wave file? Flac is lossless. Surely 2 passes can't make it more lossless?

Originally Posted by Loomes

Why doesnt it make sense, technically? As I understand 2 pass does great improvement in quality by analyzing first before processing. NeroAAC has a 2nd pass, as well as h264 which is also a VBR process in a way, roughly said. Another question is: Does qaac have a 2pass option? In foobar2000, you can give "Additional command-line encoder paths" in "Preferences: Advanced" config which I have set to C:\sfx\qaac\" but I am not sure if it accepts command line parameters for the encoder somehow.

These days foobar2000 has an encoder pack containing all the encoders it's allowed to distribute, and installs them in the foobar2000 installation folder in a sub-folder called "encoders". If foobar2000 has an encoder preset for an encoder it'll look for the encoder in there before bugging you about where to find it. You don't need to manually add encoder paths to the section in Preferences you referred to. If you try to use an encoder preset and the required file isn't in the encoder folder, foobar2000 will ask you to point it to the location and it'll add the path to that section in preferences for you.
You add command line parameters to the encoder configuration itself so you can have multiple encoder presets all using different command lines. The easiest way to start is to select a preconfigured encoder preset. Right click on a file in a playlist, select convert, click on the three dots at the bottom of the list and you're into the converter configuration.
On the right in the configuration window click on "Output Format". Click "Add New". When the next window opens there's a list of encoders at the top. Pick whichever one you want to configure, for example NeroAAC. From there select the type of encoding, and the desired quality or bitrate etc. Finally, click on the drop down list of encoders at the top again and change it to "Custom". Now instead of a slider for changing bitrate or a checkbox for choosing the encoding method you'll see the fields you'd normally fill in manually, except they'll be filled in for you. The "Parameters" field is the command line. The options foobar2000 requires will also be there, but you can add your own or change some etc before clicking okay and saving the preset. You only need the full path for the encoder if it's not located in the encoders folder.



Click "back", and you've got a links for setting the output destination and file naming, a link for adding DSPs to the conversion chain and ReplayGain is also found in there, and a link for "other" miscellaneous stuff. That whole setup can then be saved as a converter preset, and you can have lots of them should you like. They form the list you see after right clicking on files and selecting "convert" so you don't need to go through the whole process every time.



Edit: I just realise I named the Nero presets Q5.0 instead of Q0.50. I might fix that.....

There's no way to do traditional normalising with foobar2000. I don't downmix or normalise much these days anyway but if I do downmix the presets I setup include the Matrix Mixer to downmix with it's multiplier set to 0.5 to decrease the volume by a further 6dB to reduce the change of clipping. That's usually enough and if I downmix a bunch of files they all have the same relative volume to the originals. Or
I think QAAC can do it's own normalising. I think the command line option is simply -normalize. I'm not sure about any of the other usual encoders. Or
Foobar2000 can open Avisynth scripts and decode the audio (there's an Avisynth plugin for it). Create a script to decode the audio in a video file, add Normalize() to it, and Avisynth will do the normalising for you while foobar2000 converts.

I don't think QAAC has a 2 pass option (aside from normalising) but don't quote me on that.
The whole point of 2 pass is generally so the encoder can work out how to optimally distribute a fixed number of bits (according to the average bitrate you specify). If an encoder has true quality based single pass encoding method it just uses whatever bitrate is required for the specified quality. I don't know how a second pass would improve on that, but maybe I'm missing something.

[hello_hello]

Originally Posted by Loomes

eac3to "myTrack.ac3" "myTrack.wav" -normalize qaac64 "myTrack.wav" --ignorelength --no-delay --tvbr 73 --quality 2

I'd be suspecting the --quality setting only applies to CBR or maybe ABR encoding, but I couldn't find any definitive info, however VBR already has a quality setting......

For LAME MP3 the -q option effects encoding speed a fair bit. The range is 0 to 5, with zero being the best. It uses a much slower algorithm than the default -q3, hence the slower encoding but you should in theory get better quality for a specific bitrate. Most encoder GUI's seem to stick to -q2 for LAME by default. Higher quality encoding is very slow. Lame's VBR presets set their own quality too, but maybe you can over-ride that. I suspect QAAC's quality option may work in a similar fashion. Could some encoding speed tests be in order?

[Loomes]

Originally Posted by hello_hello

Finally, click on the drop down list of encoders at the top again and change it to "Custom". Now instead of a slider for changing bitrate or checkbox for encoding method you'll see the fields you'd normally fill in manually, except they'll be filled in for you. The "Parameters" field is the command line.

I missed that step somehow

--quality 2 refers to encoding speed and its the default setting of qaac so I dont really have to put it to the command line but I like to see what is happening so I tend to leave default parameters.

One more question comes to my mind: Since eac3to and qaac both can to normalization, should I do it with eac3to or qaac? I suppose it makes no difference?

[Motenai Yoda]

Originally Posted by hello_hello

For LAME MP3 the -q option effects encoding speed a fair bit. The range is 0 to 5, with zero being the best. It uses a much slower algorithm than the default -q3, hence the slower encoding but you should in theory get better quality for a specific bitrate. Most encoder GUI's seem to stick to -q2 for LAME by default. Higher quality encoding is very slow. Lame's VBR presets set their own quality too, but maybe you can over-ride that. I suspect QAAC's quality option may work in a similar fashion. Could some encoding speed tests be in order?

indeed lame 3.98+ has a relatively new slighty different -q switch levels than older ones.

=======================================================================
algorithm quality selection
=======================================================================
-q n

Bitrate is of course the main influence on quality. The higher the bitrate,
the higher the quality. But for a given bitrate, we have a choice of algorithms
to determine the best scalefactors and Huffman coding (noise shaping).

For CBR, ABR and --vbr-old modes, the following table applies

-q 0 Use the best algorithms (Best Huffman coding search, full outer
loop, and the highest precision of several parameters).
-q 1 to -q 4 Similar to -q 0 without the full outer loop and decreasing
precision of parameters the further fromm q0. -q 3 is the default
-q 5 and -q 6 Same as -q 7, but enables noise shaping and increases subblock
gain
-q 7 to -q 9 Same as -f. Very fast, OK quality. Psychoacoustics are used for
pre-echo and mid/side stereo, but no noise-shaping is done.

For the default VBR mode since LAME 3.98, the following table applies

-q 0 to -q 4 include all features of the other modes and additionally use
the best search when applying Huffman coding.
-q 5 and -q 6 include all features of -q7, calculate and consider actual
quantisation noise, and additionally enable subblock gain.
-q 7 to -q 9 This level uses a psymodel but does not calculate quantisation
noise when encoding: it takes a quick guess.

ie vbr encodes -q0 give bit identical files than -q4, the same for vbr/cbr/abr/vbr-old 5~6 and 7~9
but isn't true for bitrate-based/vbr-old ones 0~4.

ps -q2 for lame was the same as the recommended and now dismissed -h switch