Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > Audio encoding

Reply
 
Thread Tools Search this Thread Display Modes
Old 16th June 2008, 08:04   #1  |  Link
looney
Registered User
 
Join Date: Mar 2006
Location: Jamaica
Posts: 48
AC3-5.1 to AAC-5.1 .... some info header tool?

I used BeLight/BeSweet with Nero6 aac to reencode ac3 audio to aac-5.1. But resulting aac audio file is always without lot of details which is very noticable comparing it to ac3 original no matter if I even use [Transcode] quality option or just [Streaming].

First I thought it was something with nero aac library, but than i transcode it to ogg 5.1 and it gave me totaly wrong channel order center get on left, left on right. So it gave me thought that aac might also produce wrong channel order and that's the reason why i dont hear the same sound from ac3 and aac files.

Is there any tool that could give an info about channel configuration inside the encoded files? So that I can be sure that all channels are in the same order in transcoded file as they're in ac3.

Or is this maybe an decoder that produces the ottputs on the wrong channels?
looney is offline   Reply With Quote
Old 16th June 2008, 13:24   #2  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 5,662
Is know that standalone oggenc produce wrong channel mapping but NeroAacEnc work fine.

If you use Belight to encode the channelmap must be corrected but, please, put the log file to see versions or options problematics.

You can use also Foobar2000 or BeHappy-AviSynth to do the job without worry about channelmapping.

Quote:
Is there any tool that could give an info about channel configuration inside the encoded files? So that I can be sure that all channels are in the same order in transcoded file as they're in ac3.
The internal channel order in encoded formats isn't relevant. Is always fix in each format. The problem is when a decoder output uncompressed data in other order than FL-FR-FC-LF-BL-BR or when a encoder read uncompressed audio data thinking the order is different than FL-FR-FC-LF-BL-BR (like oggenc for instance, maybe bug corrected in next version)

The problem is the decoder and/or encoder used.
tebasuna51 is offline   Reply With Quote
Old 17th June 2008, 06:55   #3  |  Link
looney
Registered User
 
Join Date: Mar 2006
Location: Jamaica
Posts: 48
Quote:
Originally Posted by tebasuna51 View Post
Is know that standalone oggenc produce wrong channel mapping but NeroAacEnc work fine.

If you use Belight to encode the channelmap must be corrected but, please, put the log file to see versions or options problematics.
Heh i dont have a log file cause i'm pretty newbie (from my point of view) and cause that needs an additional switch (option) that i must put manually in the options on CL that BeLight sends direct to BeSweet.exe. It be nice to have a checkbox in BeLight GUI for that (just wishes). Yes i used libvorbis.dll (from libvorbisaoTuVb5.5P4) w BL and get that crappy encodes so i should say it stays within the used library.

Well i did a further research and go to install that bulk waste of disk space called Nero7.10 and found out of precious WaveEditor (yeah right). I opened encoded files (aac and ac3) in it and see that the channel order is the same (visually) while in ogg were like L C R SL SR LFE, comparing it to ac3 and assuming that L R C LFE SL SR is the right order at least that the way shown in NeroWE [Transport] tab.
But playing it (ac3 and aac) simultaneously (pretty much as it could be caouse i cant start them totaly in the same second) and looking on maxed Spectrum analyser tab i saw that aac files are somewhat -20dB or more below the original ac3 file level. That encoding has been done with aac/aacenc32.dll

Now i'm trying with latest BeLight that uses neroaac_cli.exe (from Nero DA). And there's a bug in BeLight ... it always uses default -q 0.5 quality (cbr) from Streaming mode no matter what is selected in BeLight GUI (Normal,Extreme....). And even HE is checked it uses default LC encoding in fact. With the old BL+aac.ddl i get in fact an opposite behaviour i checked LC and files sometimes (4 of 20 times) came out as the prefferd aac.ddl HE-AAC. Weird, but i can only use that library with BeLight.
Not to mention how LC is pain the ass giving a large files out (even streaming quality is larger than original ac3) and it takes 2-2,5x longer to encode than equivalent quality HE-AAC. Gives me wondering cause i'd expect "Low Complexity" encoding should be faster than "High Efficiency" at least that how FAAC behaved afairc. Same weird slowness w LC checked on old aac.ddl in BeLight 0.220b9

Well Nero LC-AAC at least gives out now a proper audio levels.
ED: Well after all i must correct myself it gives a decent audio levels. Almost the same for one weird output file of ~700kbps from 448kbps ac3, weird output cause i encoded it with old look gui from nero_nd available probably thru old BeLight.ini in the same folder where were the old filse. Now when i get the new look (and options) for NeroCLI GUI i stuck with pretty much the same problem app -15dB lower sounds on trancoded ~400kbps files, and no matter what -q i set in -bsn( -vbr q-aacprofile_he -6chnew ) i always get the same output filesize (probably -q 0.5 but now is twice smaller than with the same BeSweet cli option just proper gui)
NeroAACEnc.exe is about 36% slower than aacenc32.dll (960s vs 1500s). "I was gonna try enc_aacplus.exe but everybody swears that neroAAC is the best, and enc_aacplus.exe there's no GUI for directly transcode ac3 to aac afaik."

One iritating thing with new BL is that all settings are erased on exit. And it's always on streaming (-q 0.5) , hm :/ It was a nice feature of the old BLb9 that all settings were saved on exit.
ED: It seems that for new look Nero_CLI GUI you should select that from pad (No matter if it's falsely preselected!! So you should change to faac for exam, and then to NeroCLI) but i get the new interface from the toolbar menu . It pretty fussy considering aac is the way to go and has three submenues not like other encoders just one submenu.

NTM, that choosing output filename (and auto rename the .log filename from it's name) in BeLight would be usefull feature.


Quote:
Originally Posted by tebasuna51 View Post
You can use also Foobar2000 or BeHappy-AviSynth to do the job without worry about channelmapping.
So it's failsafe to do ogg encodings that way. It's few more steps that must be applied but it's good to know that there's some way to done it properly. I wouldn't surprise myself to find out that i'd need more help with it. I found myself a Quick Guide when i was looking if there's some better solutions than BeLight. But I dont know if it was in that thread someone mention some mess also with that AviSynth filter (probably for transcoding hdstreams).
Well I was looking for any other encoder than aac when it didn't gave me the expected results, there's too much masking for my taste with lowering audio levels for 20-25dB. And ogg seems like good way of testing is there something wrong with my other BeSweet options but in the end it couldn't be used for any test cause of mess up with channels that it done.



Quote:
Originally Posted by tebasuna51 View Post
The internal channel order in encoded formats isn't relevant. Is always fix in each format. The problem is when a decoder output uncompressed data in other order than FL-FR-FC-LF-BL-BR or when a encoder read uncompressed audio data thinking the order is different than FL-FR-FC-LF-BL-BR (like oggenc for instance, maybe bug corrected in next version)

The problem is the decoder and/or encoder used.
Well that i assume only a slight problem for a newbie is to find ot which one is good enough to start with

I keep my fingers crossed for ogg also but they have prior things to do now when Nokia tries to force them out from the html5 standard cause "w3c are not standardizing authority". Not to mention (by the Nokia) how may false prophet standards are floating around but no they try to fist out nitty format like vorbis/ogg (and all that comes with it). Not that it hasnt issues but 3gpp-s also have them.

Last edited by looney; 17th June 2008 at 09:43.
looney is offline   Reply With Quote
Old 17th June 2008, 12:56   #4  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 5,662
Quote:
Originally Posted by looney View Post
...BeLight...
When we need transcode between formats always we need decode to uncompressed audio formats, AudioFormat 1 (int) or 3 (float) in WAV container, and after re-encode to the new format.

The uncompressed audio data can be written in physical disk files or be passed by STDOUT-STDIN between decoder-encoder but the most common method to pass parameters is send/write a WAV header and after the raw audio data.

There are two typical problems, managing multichannel audio, with WAV headers:

1) With old standard wav headers don't exist a method to determine the channels presents (only the number). To solve this problem (and others) born the WAFE_FORMAT_EXTENSIBLE (WFE) header proposed by MS in the Multchaud document (my old versions is: Revision Number 00.05.00 1999 ). Now a channel order is mandatory and a new parameter (ChannelMask) define the channels present.

2) The second problem (not solved with WFE) is the limited size, there are two header fields (for file size and audio data size) with only 4 bytes, then these fields can be valid only for filesizes <4GB (only 31 min. for a 7.1, 24 bit, 96 KHz). The problem is solved with new wav headers W64 and RF64.

BeSweet is a venerable soft but can't read WFE headers (can't manage ChannelMask) and the wav filesize limit is 2GB because the 4 bytes fields are read like signed int. Others functions (resample, timestretch, ...) don't work with multichannel files. Can't decode aac, dts, ...
BeSweet is abandoned without release the sources then can't be modified anymore, Kurtnoise13 was made a good job solving the channelmap problem and adapting the output to new encoders (NeroAacEnc, Aften, ...) with new bsn.dll, but, I think, we can't wait new BeLight releases (I let Kurtnoise answer you in BeLight thread).

Quote:
...NeroAACEnc.exe...
To reencode ac3 use -q 0.2 to 0.4 with more quality the file is bigger than ac3. With VBR encoding don't force 'he' or 'lc' let the encoder select the appropriate, probably he for -q 0.2 and lc for -q 0.4.

I don't know volume differences between ac3 and correct reencoded aac. If you experiment any the problem can be at the ac3 decode phase (don't use DRC and Dialog Normalization).

Quote:
... enc_aacplus.exe there's no GUI for directly transcode ac3 to aac afaik...
The CT aac encoder can be selected also in BeLight or BeHappy and configured for Foobar.

I know BeHappy is a little more complex to understand. To transcode ac3 to ogg or aac you need:
- .NET Framework v2.0 installed
- AviSynth v2.5.7 installed and AviSynth filters in ...\AviSynth 2.5\plugins folder (to decode ac3 only NicAudio.dll is needed)
- A folder with:
BeHappy.exe
AvisynthWrapper.dll

and encoders to use, for instance:

neroAacEnc.exe
neroAacEnc_SSE2.exe
oggenc2.exe
enc_aacplus.dll
enc_aacPlus.exe

- the subfolder extensions (supplied with BeHappy)

Last edited by tebasuna51; 17th June 2008 at 13:00.
tebasuna51 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 23:19.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.