AC3 to AAC conversion

[Loomes]

What I have:
- A fine working streaming environment at home /w Synology NAS Server DS413j + Synology Apps on iPad, TV, PC etc.
- Loads of MP4 (h264 video + AC3 track) on my NAS, made from my DVD movies and DVD series boxes.

What I did:
- Converted DVDs to h264 video with 576p to 2000 kbps (fine for me) + AC3 track as it comes originally from the DVD (mostly 386 or even 640 kbps /w constant bitrate).

What I wanna do:
- Save even more space on my NAS by converting these AC3 tracks to AAC tracks while keeping the audio quality of the AC3 track.

My Question:
What is technically the right compression setting with NeroAACEnc to do conversion from AC3 to AAC? How is the technical background, what is the theoretical approach?

As far as I have read, AAC is way better than AC3 by saving space and quality in 2.0 and 5.1 audio tracks but I am unsure how to do it right and how far I can go re-compressing the AC3 tracks. I did some experiments with NeroAACEnc by doing "eac3to.exe mytrack.ac3 mytrack.m4a -quality=0.5 -2pass" meaning that the (already lossy) AC3 is deflated to WAV first, then compressed to M4A. I found out that a 348kbps constant AC3 will become a ~400kbps variable MP4 with slightly higher file size. Since AAC is the better compresser 0.5 cant be the right quality setting. The WAV originating from the AC3 is no better than the AC3, since AC3 is already lossy, so it makes no sense producing a bigger M4A.

What I want is to preserve the audio quality from the AC3, not loosing any more quality by doing the AAC compression. And of course I want the resulting M4A to be much smaller in file size than the AC3. Is there a trick or anything to do this properly?

Thanks in advance!

[Ghitulescu]

You won't save too much space. Save your time. For 90€ for an external HDD you can have (or save yourself) 2500 processing hours (or 14 months at your current paygrade).
The only advantage is when you have to play them on devices that do not accept AC3 (like some Androids - although vlc can solve this too).

[Loomes]

- I am not spending any time, batch scripts are doing this
- a NAS can only accept a limited amount of hard drives
- AAC playback is much more compatible with the synology apps
- filesize saved does barely count on a few files but on 3TB with movies and series it counts in large amounts

[manolito]

You will have to conduct some listening tests to compare the quality of your AC3 sources with AAC at different quality levels (using some high quality audio sources).

In my experience using the Nero encoder you can go as low as 0.30 for the quality level. This translates roughly to an average bitrate of 96 kbps for stereo and 192 kbps for 6-ch audio. (You should use quality based conversions, not bitrate based).

You might get better quality by replacing Nero with Qaac. There seems to be consensus that Qaac delivers slightly higher quality at lower bitrates. The quality values for Qaac do not match the Nero settings, a Nero setting of 0.30 is roughly equivalent to a Qaac setting of 37.


Cheers
manolito

[Loomes]

Thanks for your reply, manolito. I will check Qaac, havent heard of it yet. Ofc listening to the conversion results is mandatory but I was hoping for some more technical advice, e.g. like "AC3 640kbps is like Nero 0.4 and AC3 384kbps is like Nero 0.3". But that would be too easy I guess...

[manolito]

But that would be too easy I guess...

Yes, much too easy...

First of all these are two very different compression formats, the only thing you can count on is that usually AAC is more effective than AC3. By how much depends a lot on the source material.

Also you are comparing AC3 with constant bitrate (this is what DVDs use) to AAC with variable bitrate. Of course you can also convert to AAC using constant bitrate, but this is not recommended, you would be wasting bitrate (sure would make it easier to establish a rule of thumb relation between AC3 bitrate and the equivalent AAC bitrate).


Cheers
manolito

[Loomes]

There is one thing I dont really get: Lets say we have a AC3 of about 96kbps, which is rather poor quality. Now I decompress this AC3 to WAV and compress the WAV with a Nero quality setting of 0.5, which is rather high. The resulting M4A is way more bigger in file size but of same quality as the AC3 -- since AAC cant bring back what was lost during the original AC3 compression.

Why is the resulting M4A bigger? As I understand, audio compression is (roughly said) leaving out data you dont really need. This originally left out data does not exist anymore in the WAV. So how can a M4A be bigger when the WAV comes from a strongly compressed AC3? Naivly, I imagine that Nero's algorithm is supposed to recognize that a quality of 0.5 cant be done anymore with this WAV and instead sticks with the original quality of the AC3 (because this is the highest quality it can get from the WAV). Instead, Nero produces even a bigger file.

[manolito]

After you have decompressed the 96 kbps AC3 file to WAV, no encoder will be able to tell that this WAV comes from a heavily compressed AC3. This WAV will of course have all the artifacts and low bitrate precision problems, but to the encoder it means that it will do the best it can to encode all these artifacts and deficiencies.

Use a still picture JPG as an example. At a very high compression you will see plenty of the typical blocking, but if you try to recompress this JPG to another JPG, the converter will try to compress these blocking artifacts as faithfully as it can. And the decoded file will not be any easier to compress than a high quality file without any blocking artifacts.


Cheers
manolito

[kypec]

I agree with manolito here. I also convert all audio in my encodings to AAC, originally I was using eac3to+NeroAACEnc but switched to eac3to+qaac about 2 years ago.
This is my typical command for stereo audio in TV shows:set eac3to="%PROGRAMFILES(X86)%\AVTools\eac3to\eac3to.exe"
set qaac="%PROGRAMFILES(X86)%\AVTools\qaac\qaac.exe"

for %%a in (*.mkv) do (
%eac3to% "%%a" 2: stdout.wav -downStereo -normalize -log="%%~na_dec.log" | %qaac% --abr 80 --quality 2 -o "%%~na.m4a" --log "%%~na_enc.log" -
)

Filesize savings are quite nice, especially when you strip off multichannel AC3 384kbps -> AAC 80kbps for entire series (10 seasons * 24 episodes) without noticeable audio quality loss.:p

[Loomes]

Manolito, Kypec, thanks for your replies, very interesting and useful so far.

Kypec, thanks for sharing your command line, I have some questions:
- Why do you choose abr and not tvbr, whats the difference? As I understand, --tvbr 82 would bring same results, no?
- Is the option -normalize for adjusting the volume? If yes, any normalization I know costs quality. Is that not right?
- What settings do you use for AC3 640kbps, TrueHD, DTS and DTS-HD?
- As I am planning to get a 5.1 system in near future I would not get down to 2.0. Would you recommend other settings for AC3 384kbps 5.1 -> AAC 5.1?

[hello_hello]

Normalising won't cost you quality, It's adjusts the volume so the peaks are at maximum. As different audio tracks have different peak levels, it means they'll be adjusted by different amounts. Mostly not much, but sometimes by more than not much.

I don't normalise when converting stereo to stereo or multi-channel to multi-channel, but when downmixing it's advisable to normalise to prevent clipping.

ABR gives you the requested average bitrate. The encoder needs to guess and adjust as the encode progresses. TVBR doesn't require any of that, but you don't know what the bitrate will be. Think of ABR as being VBR with more bitrate constraints. I think for a specific bitrate ABR is generally better than CBR (unless it's a very high CBR) and TVBR should theoretically be betterer.

I don't get the concept of surround sound with the sound surrounding you as a constant reminder the picture doesn't. I find it distracting. Give me stereo any day.

I just finished writing a post on AAC encoding (http://forum.videohelp.com/threads/371441-Keep-DTS-or-convert?p=2386590&viewfull=1#post2386590) at VideoHelp. You might find some of the info useful. The main reason I switched from Nero to Apple/QAAC is the (fairly) new "no delay" option.
I don't re-encode AC3 myself as I use q.50 (Nero) which doesn't reduce the bitrate enough to make it worthwhile as a rule (unless you downmix) but DTS to AAC saves me around 1GB per movie on average, so I convert DTS. I've not experimenting with lower quality settings but it wouldn't surprise me if they sounded fine. Foobar2000's stereo bitrate estimation is similar to manolito's experience. It says around 86kbps for Q0.30 and for 96kbps it says Q0.34. I'd assume 96kbps should sound reasonable but I'd probably stick to a quality that gives you around 128kbps for stereo and foobar2000 says for Nero that's roughly Q0.40. For AAC, around 128kbps is heading into "transparent" territory, apparently. That's why all the listening tests are done at lower bitrates. I recall reading a thread at HydrogenAudio a while back where a couple of people were debating what bitrates are "transparent". I'm pretty sure the poster who was advocating around 196kbps returned to say he listened again and decided he really couldn't tell the difference between 196kbps and 128kbps.

Oh.... and all AAC encoders encode at around the same speed for quality based encoding except FhGAAC. It's fast. Up to twice the speed depending on the audio.

[Rumbah]

Well, in the latest listening test Apple AAC was sounding good with cvbr set to 96kbit/s ( http://listening-test.coresv.net/results.htm ). And that's for stereo audio listened with headphones.

With speakers or 5.1 sound I cannot hear a difference so I use qaac with tvbr set to 45. That's the rough equivalent to 96kbit/s.

And I use tvbr as movie sound tracks often have moments of silence or low volume sounds so you can save some bits this way. But you'll have to test it for yourself, I guess.

[kuchikirukia]

I don't really see a reason to skimp to the point that AAC is going to have some noticeable quality loss. If it was a 500kbps video I could see sweating the difference between 128 and 96k, but at 2000kbps it's a 1.5% difference in filesize (3% 6ch) to give it 33% more audio bitrate.
I'd QAAC tvbr 63, which should put you between 120 and 140k.

I've heard Opus ear-bleedingly artifact at 128k stereo (Miku's voice may be heavenly, but a heavily synthesized Vocaloid live in concert is a sound that God never intended to exist), so I'm hesitant to recommend anything below that bitrate without knowing that the source doesn't have much but dialogue and pleb-tier music.

[Motenai Yoda]

You can use a custom ffmpeg/avconv build with fdkaac to convert in aac vbr~4

[kypec]

Why do you choose abr and not tvbr, whats the difference? As I understand, --tvbr 82 would bring same results, no?
I want to have predictable size, especially when encoding entire TV show season for instance. Audio quality on my equipment (standard TV set built-in speakers) is sufficient for me at these AAC bitrates.
Is the option -normalize for adjusting the volume? If yes, any normalization I know costs quality. Is that not right?
Normalized volume doesn't hurt overall quality in my opinion. On the other hand, it helps me and my family members to avoid unnecessary adjustments of the sound volume after we switch from one movie to another, to sitcom episode or to kids' cartoon throughout the day.
What settings do you use for AC3 640kbps, TrueHD, DTS and DTS-HD?
- As I am planning to get a 5.1 system in near future I would not get down to 2.0. Would you recommend other settings for AC3 384kbps 5.1 -> AAC 5.1?
For 5.1 audio I use 320kbps vbr AAC. I don't have 5.1 sound system (yet) but I doubt that I would notice any quality loss with my ears. I care more for visual quality than for audio in my BD & DVD rips. Reducing DTS-HD MA to multichannel AAC can save few gigabytes on every movie for me while not hearing any audible degradation on my current (stereo only) speakers.

[hello_hello]

One more thought......

I did some experiments with NeroAACEnc by doing "eac3to.exe mytrack.ac3 mytrack.m4a -quality=0.5 -2pass" meaning that the (already lossy) AC3 is deflated to WAV first, then compressed to M4A.

How does 2 pass mode make sense for VBR encoding and is it actually possible? I assume so, given you seem to have it working, but I can't coax foobar2000 into combining 2 pass and VBR yet, although it'll happily use ABR encoding with 2 pass. Maybe I'm missing something. I wanted to see if 2 pass VBR produced a different bitrate to single pass VBR.

Normally when you specify a 2 pass encode and a bitrate you're effectively specifying a VBR encode but also the number of bits to use in total. The encoder runs the first pass to work out how to distribute the bits and the second pass encodes to output the requested average bitrate. VBR just encodes without the same bitrate limitation so I'm not sure what the point of 2 passes would be. Anyone know? Does it improve the audio quality?

[hello_hello]

I want to have predictable size, especially when encoding entire TV show season for instance. Audio quality on my equipment (standard TV set built-in speakers) is sufficient for me at these AAC bitrates.

I'd do it the other way around but I guess it depends on your workflow.
If the audio bitrate deviates too much from what's required for acceptable quality (ie lower bitrate) you might start to hear it, so if the audio bitrate has to be higher on occasion, but you lowered the video bitrate by a similar amount to compensate, I'd imagine it wouldn't be noticeable unless you're using an awfully low video bitrate to begin with (the audio/video bitrate adjustment wouldn't need to be more than 50kbps).

Rather than being wasteful by always using a higher average audio bitrate, even better would be to use a VBR quality setting you find transparent. That'd probably be more work unless you use an encoder GUI capable of encoding the audio first and then calculating the video bitrate to output the requested file size, but most of them do, don't they?

[Loomes]

Meanwhile I did some hearing tests and would use --tvbr 63 with qaac when the source is lossless Stereo. I cant hear any difference when encoding with higher quality than 63. I tested some Stereo Audio CD Rips.

Still, the question remains what quality setting in qaac makes sense when coming from lossy AC3 384kpbs 5.1. As I understand so far, you have 5 full channels and 1 channel at 1/3 the bit rate of the full channels. That would mean for 384kbps 5.1 there are 5 channels /w 72 kbps and 1 channel with 24 kbps. Is that correct? If so, how does it relate to the choosen quality setting in qaac? --tvbr 63 means about 128 kbps. Does it mean 128 are devided by 5.1 channels, meaning 5x 24kbps and 1x 8kbps? Well, I just did a test with an AC3 384kpbs 5.1 (135 MB) and

eac3to.exe my.ac3 my.wav -normalize
qaac64 my.wav --ignorelength --no-optimize --no-delay --tvbr 63 --quality 2

which resulted in a M4A 5.1 (100 MB) for which MediaInfo claims to find an overall bitrate of 296 kbps. Makes me wonder, I'm still trying to get the big picture here.

[filler56789]

Still, the question remains what quality setting in qaac makes sense when coming from lossy AC3 384kbps 5.1. As I understand so far, you have 5 full channels and 1 channel at 1/3 the bit rate of the full channels. That would mean for 384kbps 5.1 there are 5 channels /w 72 kbps and 1 channel with 24 kbps. Is that correct?

5.1 AC3 at 384kbps is "low-quality" IMHO, so (in theory at least) you could choose a qaac TVBR level even lower than 63 :devil: :)

But no, that's not correct. The ".1 channel" is supposed to contain only very-low frequencies, which makes it require a VERY-LOW bitrate for itself in a lossy compression scheme.

[detmek]

Encoding low quality audio with, again, low quality settings will result in even worse audio. Source bitrate has nothing to do with output bitrate. If you encode 32kbs mp3 with 320kbs aac you will preserve that very bad quality. If you encode 32kbs mp3 with 32kbs aac you will make audio with even worse quality.

Encoding 384kbs 5.1 AC3 does not make much sence 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.

[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]

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 (http://en.wikipedia.org/wiki/ABX_test). 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]

@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]

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]

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?

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]

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/333743-Aac-7-1?p=2158472&viewfull=1#post2158472

[tebasuna51]

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 (http://www.hydrogenaud.io/forums/index.php?showtopic=107613&view=findpost&p=882553)) 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/Encoder-configuration

[hello_hello]

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]

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

http://forum.videohelp.com/threads/333743-Aac-7-1?p=2158472&viewfull=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 (http://forum.videohelp.com/threads/367078-Need-advice-about-mixing-5-1-down-to-stereo?p=2345661&viewfull=1#post2345661) 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 (http://aften.sourceforge.net/longhelp.html) 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/Surround_sound#Channel_identification

[filler56789]

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/Multichannel--handling

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

[Loomes]

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.


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.

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]

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. (http://forum.videohelp.com/threads/333743-Aac-7-1?p=2158472&viewfull=1#post2158472)

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....

http://s27.postimg.org/galzit6pb/nero_2_1ch.jpg (http://postimg.org/image/galzit6pb/)

[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]

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?

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.

http://s16.postimg.org/yu6m4tha9/foobar_command_line.jpg (http://postimg.org/image/yu6m4tha9/)

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.

http://s22.postimg.org/h6ot07snh/foobar_converter.jpg (http://postimg.org/image/h6ot07snh/)

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 (http://s16.postimg.org/yu6m4tha9/foobar_command_line.jpg) 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() (http://avisynth.nl/index.php/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]

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]

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 :thanks:

--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]

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

[hello_hello]

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

I'd remember the quality range as being from q0 to q5 but I guess I remembered that wrong.

Cheers.

[hello_hello]

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?

I've no idea, to be honest. You'd hope the end result would be the same either way, although......... thinking about it..... for QAAC to normalise properly the audio would need to get to it "unclipped". If the peaks are already clipped then the audio is effectively already normalised, albeit with clipping.

If you set 32 as the highest BPS mode (bits per sample) in the audio encoder configuration I think that implies floating point, in which case the audio shouldn't be clipped on the way through. For a BPS mode of 24 or less that'd mean the input is integer so it probably would be clipped. I'll have to test that later..... send some audio with peaks above zero to QAAC with the BPS mode set to 32 and check to see they were normalised errrr.... normally..... and not clipped at all. I'm pretty sure with a BPS mode of 24 or less they will be, but I will test that out as it'll be handy to know. Maybe not until tomorrow, but I will.

[Ghitulescu]

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.[/url]

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?

Here's (http://forum.doom9.org/showthread.php?p=1718048#post1718048)one example :)
Lots of quatropfonic albums are encoded as 4.0 or 4.1.

[hello_hello]

Here's (http://forum.doom9.org/showthread.php?p=1718048#post1718048)one example :)
Lots of quatropfonic albums are encoded as 4.0 or 4.1.

I had a bit of a look through your thread. It seems to indicate what I suspected, that many/most hardware players/decoders aren't going to be happy with those formats either. I guess applying the same logic that's been applied to AAC here it means hardware players aren't adequate for multi-channel audio either. ;)

While I was messing around trying to create 2.1ch/3.1ch/4.1ch AAC audio yesterday I kept wondering to myself why I was bothering as if I had audio in those formats and I was wanting to re-encode it, I'd probably convert it to another format in the process? I see you thought the same thing. For ffdshow users it'd be easy enough to enable it's mixer filter and decode via DirectShow. I assume it'd be possible to convert from one multi-channel format to another using Avisynth, but I just added the Matrix Mixer DSP to foobar2000's conversion chain.

In this case I reduced the centre channel by 60dB (that seems to be the maximum) reduced the over-all gain by 60dB (for a total of -120dB), and I boosted all the other channels by 60dB to compensate. If the input had been 4.1 channel there'd be no centre channel to turn down to nothing, but you could always duplicate the LFE channel in the centre channel at -60b to create a centre channel with nothing in it that way.

Once that was done it was simply a matter of opening a 5.1ch file (because I've got no 4.1ch files) and converting it directly to 5.1ch AAC..... to simulate converting 4.1ch directly to 5.1ch AAC with a silent centre channel. All that intermediate wave file creating and editing and exporting and converting seems like it's something to be avoided if possible.

http://s18.postimg.org/6ooz1fjn9/image.jpg (http://postimg.org/image/6ooz1fjn9/) http://s17.postimg.org/iv1xc5qd7/4_1ch_converted_to_5_1ch.jpg (http://postimg.org/image/iv1xc5qd7/)

[filler56789]

I had a bit of a look through your thread. It seems to indicate what I suspected, that many/most hardware players/decoders aren't going to to happy with those formats either. I guess applying the same logic that's been applied to AAC here it means hardware players aren't adequate for multi-channel audio either. ;)

It all depends on the definition of "multichannel" which one decides to accept.
IF by "multichannel" one means 5.1-and-7.1-only, because
5.1-and-7.1 is all that has always existed :rolleyes: , ...

The point is, I myself and 5 other people :) don't back lousy specifications nor lazy implementations ;) End-Of-OT.

[Ghitulescu]

I belong to the school of thought that hardware players MUST be entrusted with playing files. Whereas computers only to proces the raw files to feed the former.

My lifetime experience showed me that people that entrust their work to software players do not benefit from the high quality of standalones and are forced to reencode the files every time the software player is changed. I ahd to do this only when the (industry) standards changed (they allow for one generation "legacy" - eg DVD players could play VCDs, BD players could play DVDs (but no VCDs) and so on).

For me it is very important to stay within indsutry standards. And one workaround (thanks again Tebasuna) is to add muted channels where the HW players expect them.

[hello_hello]

It all depends on the definition of "multichannel" which one decides to accept.

How's that? You claimed AAC isn't adequate for multi-channel encoding based on your particular definition of multi-channel and I pointed out it appears using the same definition hardware players aren't adequate either.

IF by "multichannel" one means 5.1-and-7.1-only, because 5.1-and-7.1 is all that has always existed

No I'm pretty sure multi-channel also includes all the additional multi-channel layouts AAC supports, and the lack of support for a couple of old formats doesn't change the definition.

The point is, I myself and 5 other people :) don't back lousy specifications nor lazy implementations

Is that like not being willing to buy a turntable because it won't play old 78rpm records even though you don't actually own any old 78rpm records or do you have an extensive collection of 2.1ch/3.1ch/4.1 channel audio you need to convert?

[hello_hello]

I belong to the school of thought that hardware players MUST be entrusted with playing files. Whereas computers only to proces the raw files to feed the former.

That's the double standard we've all come to admire. You must use a hardware player for playing files but if it won't, process them with a PC so it can, but don't play them with a PC because the hardware player is still somehow better. Or something.....

My lifetime experience showed me that people that entrust their work to software players do not benefit from the high quality of standalones and are forced to reencode the files every time the software player is changed. I ahd to do this only when the (industry) standards changed (they allow for one generation "legacy" - eg DVD players could play VCDs, BD players could play DVDs (but no VCDs) and so on).

Seriously? I'm calling bullshit.
Can you name one commonly used file/codec and software combination to which that would apply? Just one example? Why on earth would you change software players if it means not being able to play your files? And where did the old software player go?
Every single video file on my hard drive plays using the current version of MPC-HC and VLC and some date back to 2003.

If you encode you might want to re-encode with each new generation of codec, but that probably only happens at about the same rate of change as it does for industry standard formats.

For me it is very important to stay within indsutry standards.

And you don't see the irony of it being important to you mostly because you use industry standard players?

And one workaround (thanks again Tebasuna) is to add muted channels where the HW players expect them.

Could you clarify...... the 4.1ch audio from your audio DVDs..... how many generations old is it? It's just that using a PC to convert it to a different format compatible with your current hardware seems to completely contradict your entire post. Where did your one generation of legacy support go?

Not that I've got any issue with changing formats, only the ridiculous justifications you've offered with it.

[filler56789]

@hello_hello: I did NOT disagree with you (or with myself) about that topic.
I just thought your « ;) » was rather misplaced :)
But this is just my stupid opinion, of course :D

[Ghitulescu]

Just one example? Why on earth would you change software players if it means not being able to play your files? And where did the old software player go?
Every single video file on my hard drive plays using the current version of MPC-HC and VLC and some date back to 2003.
And you don't see the irony of it being important to you mostly because you use industry standard players?
As well as my double standard, you either kept what you could play or upgraded your players to match the files. Same Mary, different dress.
Could you clarify...... the 4.1ch audio from your audio DVDs..... how many generations old is it? It's just that using a PC to convert it to a different format compatible with your current hardware seems to completely contradict your entire post. Where did your one generation of legacy support go?

Not that I've got any issue with changing formats, only the ridiculous justifications you've offered with it.
You missed a lot of things, but you simply cannot more.
I changed the player for one that sends all data digitally (HDMI) to my AVR, instead of 6 analogue cables.
My problem was that I missed that my Pio can't do DVD-Audio.
This has nothing to do with the standards per se, just with the artificial segmentation of the market. Not a big deal, as I have only a few of them, and I will anyway buy no one in the future.

Now, that Pink Floyd SACD, if you could use google, was the Alan Parsons mix from the original 4track tapes. It was supposed to be a new standard back then, but it didn't caught.

I saved the music losslessly in a different format. One generation, bit-perfect, two in total if we count the digitization, three if the LFE is considered, too. And this will be bit-perfect also in the future, as it will be directly (losslessly, bit-perfect) repacked or used as such in the BD-audio or as the audio part of the BD-video, which is the current standard.

PS: I still burn CDs/DVDs/BDs in the old-fashioned, space-wasting, low-quality formats. And guess what, I can drop any of them in any player that belongs at least to the same generation or newer and can watch it on any TV compatible with the player. Two technical generations are always allowed.