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.

[hello_hello]

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.

So no example then? I thought not.

I've been using MPC and MPC-HC for years (the oldest MPC installer I have on my hard drive is dated 2003). I don't recall ever having deleted (or converted) a video simply because I could no longer play it using the PC (I just found the appropriate codec or installed a different player), and even if I had, it wouldn't have been a video I'd re-encoded from DVD or Bluray. Aside from mpeg1/2, mpeg4 (Xvid/Divx) and h264, have there been other formats commonly used to re-encode video? Formats that can't be played today with most software players?
The most commonly used formats MPC-HC couldn't natively play would have been RealPlayer and QuickTime but it could use their codecs if the players were installed. These days, it can play them on it's own. I image VLC can do likewise and they'd have to be the two most popular freeware players.

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.

Yes, you forgot to mention industry standard players with drives for playing two generations of discs aren't necessarily going to be able to connect correctly to other previous/future/current generation devices.

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.

Yep, we all use PCs for that sort of thing despite the fact we're apparently only supposed to use hardware players to play them, but it's doubtful in the future we'll have to downgrade software to an older version to play/edit/convert it. More likely we could just play it as it is while remapping the channels on the fly and send it out in an AVR friendly format.

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.

And for devices without a disc drive? Bum up, head in the sand?
I can put my modern, compressed, space saving files on a USB stick and play them using any player in this house. I can still burn discs if necessary. I just rarely need to.

I understand your concerns. I also tend to stick to hardware compatible formats. Not the industry standard ones, but the commonly used formats most industry standard players can also play these days.
I can't form the conclusion a hardware player will play my video with a higher quality than my PC connected to my TV via HDMI though, because I can't see a quality difference. What am I missing?

[kuchikirukia]

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

I'm with you.
I refuse to use any hard drive, USB stick, SSD, tape, floppy, CD or DVD drive because they all neglect to support reading Edison phonograph cylinders and stone etchings.


Sent from my tin can over smoke signal.

[filler56789]

I'm with you.
I refuse to use any hard drive, USB stick, SSD, tape, floppy, CD or DVD drive because they all neglect to support reading Edison phonograph cylinders and stone etchings.


Sent from my tin can over smoke signal.

Thanks for completely misunderstanding what I wrote.

Or should I say, for *pretending* :devil: to misunderstand what I wrote?
After all, some people need some "good" (read: lame) excuses for postwhoring.

Actually, your reply was rather fallacious.

[hello_hello]

I'm still trying to understand why some encoders (FDK and QAAC) actively reject some channel layouts. Others simply remap to a channel layout they want to use (FhG and Nero) which to me seems a bit naughty. I'd rather have a "no I won't do that" error message.

I played around a little with QAAC as it's the only AAC encoder I have that'll reject channel layouts it doesn't like and let you specify exactly the layout you want. I used a 4ch audio file and the standard 4ch layouts listed at the bottom of this page: https://trac.ffmpeg.org/wiki/AudioChannelManipulation#Muteachannel

They are:

3.1: FL+FR+FC+LFE
4.0: FL+FR+FC+BC
Quad: FL+FR+BL+BR
Quad: (side) FL+FR+SL+SR

When specifying a channel layout QAAC encoded the 4.0 and Quad layouts correctly, and it didn't reject the Quad (side) layout (although the Apple encoder remaps "Quad (side)" to "Quad" as explained here (https://github.com/nu774/qaac/wiki/Multichannel--handling), but it completely rejects 3.1ch. Looking at the list of channel layouts on the QAAC page I linked to that's hardly a surprise, but as none of the AAC encoders will encode 3.1ch (they either reject it or encode is as 4.0) there must be a reason for it beyond Apple not having bothered implementing 3.1ch encoding, or there's an AAC conspiracy taking place, but I'm not sure what the reason is.

I didn't play around with too many channel number/layout combinations other than the 4ch ones, but so far all the AAC encoders either refuse to encode 4.1ch or they remap it to something else, but once again I'd assume there's a reason.

And of course there's always the exception that makes the rule. 2.1ch is either encoded as 3ch or rejected, except by Nero. The Nero encoder will happily distinguish between 2.1ch and 3ch and encode either correctly. I don't know why.

[Ghitulescu]

There is no problem to make a file with any channel configuration one would like.
That an encoder/muxer rejects a file, it does because their programmers consider that certain configurations have no sense (no HW supported), not because it cannot be done.

In a Jesusian parable: a computer may equally split an invoice among 3 people, just that in real life no one can pay 33€ and 33.33 cents.

[filler56789]

Some more food for the thought:

As AC3, DTS and MLP were designed to support 1.1, 2.1, two types of 3.0/3.1 and two types of 4.0/4.1, probably their designers were thinking about the needs of the content creators/producers; I mean, if someone wants to create, for example, a 4-channel-only audio track, fine, then he/she will not need to create 2 additional dummy channels because of half-assed format_specifications /firmware /software.

Now, regarding the AAC specs:
¿why define TWO methods for identifying a channel layout? What's the point?

[nevcairiel]

There isn't really two methods to define it, there is one method to explicitly define every single channel .. and one method to simply not define anything, and let the defaults apply.
In most cases, this is because at first, there was only the implicit defaults, and then someone thought it would be nice to have support for more, and the second method was born in a addendum to the original spec.

FWIW, encoding anything that is not a "default" channel layout will cause trouble sooner or later, and if only during playback as players get confused. Ever tried sending 4 channel audio over HDMI, without modification? Good luck communicating the speaker mask to the HDMI receiver. ;)
I gave my LAV Audio a special mode that remaps all "uncommon" channel layouts into a default layout with silent channels to combat such problems. Before, I've had problems with 5.0 missing a center, since it got interpreted as 4.1 over HDMI (and some other broken combinations, too).

[hello_hello]

The way I understand it the "default" layout is the layout for wave files, which is here (under default channel ordering):

https://msdn.microsoft.com/en-us/library/windows/hardware/dn653308%28v=vs.85%29.aspx
Here's the first six.

1. Front Left - FL
2. Front Right - FR
3. Front Center - FC
4. Low Frequency - LF
5. Back Left - BL
6. Back Right - BR
7. Front Left of Center - FLC
8. Front Right of Center - FRC
9. Back Center - BC

You can't omit a channel as such, as the following channels would then "move up" one, so for example if you had a 3ch wave file that was actually channels 1, 2 and 4 you'd end up with the LFE channel in the centre channel. To enable specifying any channel configuration, the ChannelMask system is used (there's a list further down the page I linked to). The channel order remains exactly the same as above, but now you can specify which channels a wave file consists of. Without a channel mask, the default order is assumed.

The QAAC encoder is the only AAC encoder with a --chanmask command line option allowing you to over-ride the channel mapping of the wave file and set your own. For 4 channel configurations......

3.1: FL+FR+FC+LFE - 0x00000015
4.0: FL+FR+FC+BC - 0x00000107
Quad: FL+FR+BL+BR - 0x00000033
Quad: (side) FL+FR+SL+SR - 0x00000603 (QAAC remaps this to the Quad channel layout internally)

Please feel free to check I'm using the correct channel masks, but QAAC will accept any of the above channel masks in the command line except the first, which it rejects. It encodes the rest correctly (aside from internally remapping SL+SR to BL+BR). If you try to encode a 4ch wave file with the 3.1ch mask using any of the AAC encoders, it'll either be remapped to the 4.0ch mapping without warning, or it'll be rejected (depending on the encoder).

I'm not yet subscribing to an AAC conspiracy theory, so I'm trying to understand why that'd be when I don't see any reason why AAC couldn't be used to encode 3.1ch (or any channel mask you care to specify), at least in theory, yet all the AAC encoders refuse to do so. There must be a reason for it. A reason why 3.1ch AAC must be a bad thing..... I assume?

It might relate to hardware players/receivers generally not knowing what 3.1ch is and assuming it's some other 4ch configuration, although that'd mean hardware players would be similarly ignorant of 4.1ch, and those designing the specs for AAC decided that'd be a good reason for those formats to be illegal. That still leaves the 2.1ch exception unexplained though, in respect to why Nero will encode 2.1ch correctly but the rest of the AAC encoder won't.

Now, regarding the AAC specs:
¿why define TWO methods for identifying a channel layout? What's the point?

Other than the above, is there another method? The post you linked to earlier (http://forum.videohelp.com/threads/333743-Aac-7-1?p=2158472&viewfull=1#post2158472) refers to a "program_config_element()" or lack thereof, and how AAC channel ordering is handled without it.
I'd been working under the assumption it's used to specify the default AAC channel ordering for encoding, but now I think it's just specifying the default mapping for decoding when there's none specified in the AAC stream itself.

The link refers to SCE's, CPE's and LFE's and how they're assigned to channels when no assignment is specified.
Understanding AAC (http://wiki.multimedia.cx/index.php?title=Understanding_AAC)
SCE = single channel element
CPE= channel pair element
LFE = low frequency element

If the number of single channel elements is odd they're output starting at the centre speaker and from there in pairs outwards (front left+right, back left+right etc). If there's an even number they start with left and right.
A CPE seems to be counted as two SCE's so the same method of assigning channels is still used when there's a combination of SCE's and CPE's.
I'm thinking it even conforms to the wave file channel order with the LFE channel removed (although I'm not 100% sure there). It seems AAC knows the difference between a SCE and a LFE but there's no default speaker mapping for multiple LFE's.

And that makes sense when you look at the order in which AAC stores encoded audio (for 5.1ch).
FC FL FR SL SR LFE
It'd be encoded as a SCE, two CPEs and a LFE.

Mind you even the implicit channel ordering seems to indicate not only is 3.1ch AAC possible, if there's no explicit channel mapping, three channels and a LFE should result in 3.1ch output, the way I read it.......
There must be a reason.....

[Ghitulescu]

Unfortunately, there was no intention from Microsoft to finalize things.

Historically they may suggest they intend to finish the things, for instance to set legal values for the myriad of RESERVED fields and values all over their data structures, but they never did this. They simply created a new, usually incompatible format, and went along.

I don't know why hello_hello considers that particular sequence to be THE ONE, namely FL, FR, FC, LFE, BL, BR, when some of the first creators of a multi channel sound files, eg Dolby, specified a different order, namely L, C, R, BL, BR, LFE in 1991, when Microsoft just finished to set the RIFF adaptation to WAV.

So, once again, Microsoft comes 2007 and stir the standards to a new assignment (when she realised multichannel audio is the future). Why did she this? Because she could. Microsoft showed people that she'll not obey other party standards but her own. That's the power of a (quasi)monopole. Those that impose the rules always win.

Concerning the HW players and unusual channel configurations. Well, these had no problems to map correctly the channels, as no Microsoft "imagination" was involved in this. A DVD-Audio player would play 4.1 files perfectly (L,R,LFE,Ls,Rs). A computer relying on Microsoft code and formats would have a problem, unless the programmers managed to get workarounds (like custom channel mapping and stuff).

[hello_hello]

Unfortunately, there was no intention from Microsoft to finalise things.

Mono and stereo wave files have been around for a long time. I think the idea behind the wave file channel ordering was simply to increase the number of channels without making too much of a mess. When the two channels in a stereo wave file are left and right, why when you add a third (ie centre) would it be logical to put it in the middle?

I don't know why hello_hello considers that particular sequence to be THE ONE, namely FL, FR, FC, LFE, BL, BR, when some of the first creators of a multi channel sound files, eg Dolby, specified a different order, namely L, C, R, BL, BR, LFE in 1991, when Microsoft just finished to set the RIFF adaptation to WAV.

The wave file format is THE intermediate PC format used when converting between one format and another. Import a 5.1ch AC3 file into Audacity and then do the same for 5.1ch AAC file. They'll both be imported using the wave file channel order.
Re-encode from one format to another and it'll be decoded using the channel order for wave files and a wave file channel mask for the encoder to know which particular channels are included. I don't know why that needs explaining to Ghitulescu unless some decoders decode use a different channel order and encoders accept different channel masks to define the input channels.

Concerning the HW players and unusual channel configurations. Well, these had no problems to map correctly the channels, as no Microsoft "imagination" was involved in this. A DVD-Audio player would play 4.1 files perfectly (L,R,LFE,Ls,Rs). A computer relying on Microsoft code and formats would have a problem, unless the programmers managed to get workarounds (like custom channel mapping and stuff).

So your recent efforts to convert 4.1ch audio to 5.1ch audio? That was all Microsoft's fault and nothing to do with your hardware not decoding 4.1ch correctly?

[Ghitulescu]

I think the idea behind the wave file channel ordering was simply to increase the number of channels without making too much of a mess.
The original RIFF/WAV specs allowed for this.
When the two channels in a stereo wave file are left and right, why when you add a third (ie centre) would it be logical to put it in the middle?
No. When stereo appeared (stereo doesn't mean 2 channels but spatial), people put a number of speakers around the listener. It was the need of a researcher and his paper to demonstrate that stereophonic image can be obtained with only 2 speakers. So 3 speakers were a triangle. Like 4 channels in the '70ies were placed around the listener not all in front of him. Therefore a third channel is more logical to be Center-Back rather than Center-Front.
The wave file format is THE intermediate PC format used when converting between one format and another. Import a 5.1ch AC3 file into Audacity and then do the same for 5.1ch AAC file. They'll both be imported using the wave file channel order.
It is not. Audacity does not need AFAIK to convert to WAV any file it processes. It converts them however to raw (L)PCM which is not WAV.

I wonder how the engineers at Dolby or in Hollywood converted the audio to Dolby 5.1 when WAV lacked this possibility. Hm, Hm, Hm :)
I don't know why that needs explaining to Ghitulescu unless some decoders decode use a different channel order and encoders accept different channel masks to define the input channels.
Half-knowing is dangerous, as I see :)
Channel mask is the MS invention. Dolby had presets: 4 channels could only mean L,R,Ls,Rs, and this could be combined with LFE to get 4.1.
So your recent efforts to convert 4.1ch audio to 5.1ch audio? That was all Microsoft's fault and nothing to do with your hardware not decoding 4.1ch correctly?
No, the hardware correctly decoded the files that were not WAV, but I could not get there without passing through WAV due to the tools I am allowed to use. 4.1 it is allowed in Dolby Digital (also in real life, as the video part was dolbidised), see above.

[hello_hello]

Anyway......

After a bit more research it seems the info in the post filler56789 (http://forum.videohelp.com/threads/333743-Aac-7-1?p=2158472&viewfull=1#post2158472) linked to is correct, only maybe it's been interpreted backwards.
The conclusions was:
"As already expected, most encoders and decoders use only the "implicit channel mapping"".
However I think it's exactly the opposite. They'll mostly only use the "explicit" channel mapping, because the "implicit" channel mapping implies 3.1ch AAC encoding is possible. The "explicit" channel mapping however only includes a pre-defined set of channel mappings.

The info in the above link refers to "16 available PCE’s" to define channel mappings. The first seven are listed here:
http://spectralhole.blogspot.com.au/2010/08/aac-bistream-flaws-part-1-channel-model.html

Just as I thought I was onto a logical explanation it occurred to me there seems to be only one official PCE for 4ch audio, and that's for a 4ch layout consisting of front stereo, front centre and a rear surround channel (the 4.0ch layout mentioned in my earlier post), yet QAAC will still accept and encode the two 4ch QUAD mappings, but not 3.1ch...... there must be a logical reason for that.

[hello_hello]

No. When stereo appeared (stereo doesn't mean 2 channels but spatial), people put a number of speakers around the listener. It was the need of a researcher and his paper to demonstrate that stereophonic image can be obtained with only 2 speakers. So 3 speakers were a triangle. Like 4 channels in the '70ies were placed around the listener not all in front of him. Therefore a third channel is more logical to be Center-Back rather than Center-Front.

I'm not talking about the position of speakers, I'm talking about the physical wave file itself. You can sit on the third speaker for all it matters, but when you add a third channel to a wave file consisting of two channels that'd normally be decoded as stereo, why would you put it in the middle? Why wouldn't you keep the first two channels as stereo channels and add the third channel as a third channel?

It is not. Audacity does not need AFAIK to convert to WAV any file it processes. It converts them however to raw (L)PCM which is not WAV.

Why is it so hard for you to understand a simple point? I never said they're imported as wave files. I said they're imported using the wave file channel order.
Import a 5.1ch file into Audacity and look at the physical order. ie the order the channels appear in the GUI. It's the wave file channel order. It doesn't matter what format you import or the channel order that format uses, they're imported using THE common channel order. The channel order for wave files.
And no, I didn't say they were imported as wave files, in case you're still confused.

I wonder how the engineers at Dolby or in Hollywood converted the audio to Dolby 5.1 when WAV lacked this possibility. Hm, Hm, Hm :)

I don't know, but you're telling the story and it's not going to be satisfying until we learn how it ends. How did they do it?

Half-knowing is dangerous, as I see :)
Channel mask is the MS invention. Dolby had presets: 4 channels could only mean L,R,Ls,Rs, and this could be combined with LFE to get 4.1.

Nobody said it wasn't a Microsoft invention, but HHEELLOO!!!!! We're referring to using a PC and for a PC when decoding different formats and/or encoding using different codecs it's standard to use the wave file channel ordering and wave file channel mask as an intermediate format. I've never said anything different.

No, the hardware correctly decoded the files that were not WAV, but I could not get there without passing through WAV due to the tools I am allowed to use. 4.1 it is allowed in Dolby Digital (also in real life, as the video part was dolbidised), see above.

Did you need to convert your 4.1ch files to 5.1ch for you AVR to decode them correctly as per your thread, or was there really some other reason for it you're now only just revealing?

[filler56789]

........
......
..........

there must be a logical reason for that.

There must be a reason? Surely.
But does that reason have to be *logical*? Not at all.

Human beings are notorious for being illogical and irrational. And unfortunately, becoming a (self-declared) "champion of (PSEUDO-)skepticism and (Illuminist) rationality" invariably only makes the disease worse :D

[hello_hello]

Well I tried, but so far nothing as simple as "the freeware AAC encoders don't support 3.1ch audio because....." on any web page I've looked at. I still think there must be a logical explanation, if for no other reason than they're all the same. It's not like one encoder encodes it while another won't, but no matter how rational or irrational that reason may be, I'm yet to find it. :(

[Ghitulescu]

Did you need to convert your 4.1ch files to 5.1ch for you AVR to decode them correctly as per your thread, or was there really some other reason for it you're now only just revealing?
My AVR works just fine. But I was in need to convert a 4.1 (no centre) audio to something I can use. And ran into WAV peculiarities and software shortcoming.

In case you overthink instead of reading, I changed the player and not double checking some information.

The AAC standard 13818-7 allows for whatever channel combination and order. If one particular encoder does not like a particular configuration it's entirely its (encoder) fault.

In the case of 3.1 the standard does not allow it if the configuration is Left, Right, Centre and LFE the can only be one single channel, and this is the LFE. All others must be paired. The trick would be to allocate two channels (center left and cenjter right) to represent C (dual mono).

[hello_hello]

My AVR works just fine. But I was in need to convert a 4.1 (no centre) audio to something I can use. And ran into WAV peculiarities and software shortcoming.

In case you overthink instead of reading, I changed the player and not double checking some information.

I'm not over-thinking anything. I'm trying hard not to think about your logic behind having to convert formats that you claimed were being decoded correctly.

The AAC standard 13818-7 allows for whatever channel combination and order. If one particular encoder does not like a particular configuration it's entirely its (encoder) fault.

There must be an AAC encoder conspiracy taking place then.

In the case of 3.1 the standard does not allow it if the configuration is Left, Right, Centre and LFE the can only be one single channel, and this is the LFE. All others must be paired. The trick would be to allocate two channels (center left and cenjter right) to represent C (dual mono).

So the standard allows for any channel combination, and if an encoder doesn't like a configuration it's the encoder's fault, except for 3.1ch because the standard that allows for any configuration doesn't allow for 3.1ch. Is that how it works?

That definitely sounds like something you just made up again. How do you explain 5.1ch? Doesn't it consist of 2 pairs of channels and two single channels? What about 4ch? Doesn't it have two single channels? Front left and right (paired channel) plus front centre and rear surround, both being single channels? According to Table 42 on page 61 of this pdf, (www.nhzjj.com/asp/admin/editor/newsfile/201031816243950.pdf) the 4.0ch configuration definitely contains two single channel elements.

[Ghitulescu]

I'm not over-thinking anything. I'm trying hard not to think about your logic behind having to convert formats that you claimed were being decoded correctly.
It is a behaviour at you NOT TO understand what is written. I mean to try to twist what has been said in order to make you like having right when you're obviously wrong. I changed the player and the DVD-A was not supported in the new one (although some reviewers mentioned it). DVD-A and SACD are rather dead and toys implementing both are rare. It is my fault for not double checking this. Since I own olny a few DVD-A discs I decided to convert them to a format my new player accepts, either a DVD-V with lossless audio, or a collection of FLACs, rather than to buy a new, universal player, matching my existing rig.
But when the pieces of gear work - they work. They can't afford to wait for a firmware upgrade or to ask for downloading of a new codec or codec-pack as on a computer. They have to work right out-of-the-box. Besides, a 4.1 DVD-A disc would not be sold if this combination of channels would be unsupported by the players it is designed for.
According to Table 42 on page 61, the 4.0ch configuration definitely contains two single channel elements.
Table 42 reads, for 4 channels, the following and only configuration
4 ¦ 4 ¦ single_channel_element(center front speaker), channel_pair_element(left, right center front speakers), single_channel_element(rear surround).

So it's a 3 center front-speakers and a single rear one configuration. Hardly a real-life configuration (unless one implements true L and R to be stored as LFC and RFC). This is how I read them. I am not sure this configuration has anything to do with your expectations of a 3.1 configuration (most probably L, R, C and LFE).
But this are the implicit/default matrixes. In other words, if you send a 4-substreams file to any AAC-encoder that encoder has to use the default matrix (table 42) to assign the channels.
If you don't want this stupid 4-chn matrix you have to use a custom assignment, as per clause 8.5.3.2. Wherein Any SCE’s except the last SCE must be paired, and the presence of exactly two SCE’s (alone or preceeded by a CPE) indicates that the two SCE’s are Left and Right Rear center, respectively.So, you may have: CPEs (already paired) and paired SCEs but only the last SCE in the list may be a "bachelor" (usually LFE).

Because LFE always was a single channel (since Dolby implemented it in 1991).

Why this strange pairing? For encoding economy - in short, pair channels may be encoded as MS (Mid+Side), known as joint stereo in MP3.
Single channels are reserved for channels carrying important information, like L and R, although they can also be present as a pair (probably to allow an even lower bitrate).

[hello_hello]

It is a behaviour at you NOT TO understand what is written. I mean to try to twist what has been said in order to make you like having right when you're obviously wrong.

I understand exactly what's written and I don't need to try to twist anything.
I'm fully aware you had to convert the 4.1ch audio to 5.1ch. I never said you didn't. I just don't know why it requires references to Microsoft when you're using a hardware player and it's got nothing to do with the topic. It's just you once again dragging a thread off on a tangent because you like to pretend you know what you're talking about and you thought my references to the wave file format was an opportunity to display how clever you think you are, only once again you didn't understand what was being said and the result was another of your tangents.
Stating I'm obviously wrong is hilarious coming from you when you've ignored almost entire posts in this thread because they've proved you wrong.

Table 42 reads, for 4 channels, the following and only configuration
4 ¦ 4 ¦ single_channel_element(center front speaker), channel_pair_element(left, right center front speakers), single_channel_element(rear surround).

So it's a 3 center front-speakers and a single rear one configuration. Hardly a real-life configuration (unless one implements true L and R to be stored as LFC and RFC). This is how I read them.
I am not sure this configuration has anything to do with your expectations of a 3.1 configuration (most probably L, R, C and LFE).

Foobar2000 displays 4.0ch audio consisting of a front centre channel, front left and right channels, and a rear centre channel.
Whether it's labelled as rear centre or rear surround I don't see how it's any different to 3.1ch except there's a rear centre channel instead of a LFE channel. It's specified as two single channel elements and one channel pair element, a configuration you said wasn't allowed because only one unpaired SCE was allowed.

But this are the implicit/default matrixes. In other words, if you send a 4-substreams file to any AAC-encoder that encoder has to use the default matrix (table 42) to assign the channels.
If you don't want this stupid 4-chn matrix you have to use a custom assignment, as per clause 8.5.3.2.

So it can use the stupid 4ch matrix despite your claim there can only be one unpaired single channel, or is that somehow still true even while we talk about the 4ch configuration with two unpaired SCEs?

Any SCE’s except the last SCE must be paired, and the presence of exactly two SCE’s (alone or preceeded by a CPE) indicates that the two SCE’s are Left and Right Rear center, respectively.

Let's include the part of 8.5.3.2 you ignored because it didn't suit you.

Included in the PCE are “list of front channels”, using the rule center outwards, left before right. In this list, a center channel SCE, if any, must come first, and any other SCE’s must appear in pairs, constituting an LR pair.

After the list of front channels, there is a list of “side channels” consisting of CPE’s, or of pairs of SCE’s. These are listed in the order of front to back. Again, in the case of a pair of SCE’s, the first is a left channel, the second a right channel.

After the list of side channels, a list of back channels is available, listed from outside in. Any SCE’s except the last SCE must be paired, and the presence of exactly two SCE’s (alone or preceeded by a CPE) indicates that the two SCE’s are Left and Right Rear center, respectively.

Obviously you can start with a non-paired SCE and end with a non-paired SCE and every time I add one single SCE to another single SCE I get two single SCEs. Didn't you say there could only be one?
The default 4ch matrix follows the rule exactly as described. Unpaired SCE (centre), paired SCE(L&R), unpaired SCE (rear).

So, you may have: CPEs (already paired) and paired SCEs but only the last SCE in the list may be a "bachelor" (usually LFE).
Because LFE always was a single channel (since Dolby implemented it in 1991).

The AAC spec clearly distinguishes between a LFE and a SCE so the last SCE in the chain is not assumed to be an LFE channel. That's just something new you've made up. Only a LFE channel is assumed to be an LFE channel.
You only have to think about 5.1ch audio for ten seconds to see your claim makes no sense. Front LR is a pair, rear LR is a pair, the LFE channel is unpaired, so where does that leave the centre channel when there can't be another unpaired SCE? Obviously 3.1ch is the same as 5.1ch with a pair of SCEs removed. How then can 3.1ch not be allowed??

Other elements are also specified. A list of one or more LFE’s is specified for application to this program.

Why this strange pairing? For encoding economy - in short, pair channels may be encoded as MS (Mid+Side), known as joint stereo in MP3.
Single channels are reserved for channels carrying important information, like L and R, although they can also be present as a pair (probably to allow an even lower bitrate).

You sure you're not making it up as you go again? Why have SCEs if they're going to be encoded as joint stereo? It seems more likely that the definition of a pair of SCEs encoded using joint stereo would be a CPE.
And why can't you encode important channels like L and R using joint stereo? Wouldn't that kind of be the point of it?

[tebasuna51]

Please guys let's go.

Last posts are useless for others users.