Headac3he audio encoding replacement for GKnot

[SSJ4_Gojita]

www.everwicked.com has released a tool that lets you encode audio in GKnot with headac3he instead of the integrated BeSweet for those of you who like headac3he's features.

[everwicked]

Hopefully now people will stop complaining about speed.

Any feature requests/bug reports at all?

Hope you like it :)

[facts]

i had issues with besweet crashing on a couple of my encodes, so thanks everwicked.

[Apfelstruhdl]

REAL support of Headac3he would be better....

Maybe implent an option for choosing between besweet and ac3he??!!!

[everwicked]

@facts
I take that it works fine then :)

@Apfelstruhdl
Bother theWEV for that :rolleyes:

[everwicked]

By the way, I could easily add support for float mode (it now defaults to dumb mode which is slower)

Let me know if you'd like that.

[canman]

I believe the username is TheWEF and not theWEV :angry: (Total lack of respect that you don't edit your post and retype his nickname)

[diji1]

canman : I believe the username is TheWEF and not theWEV (Total lack of respect that you don't edit your post and retype his nickname)

prolly he has other things to do like run his website :)

[cofferscuffs]

I think theWEF is concentrating on his new project, and there won't be a new Gknot unless it manages to format your system all by itself...

[canman]

Originally posted by diji1
prolly he has other things to do like run his website :) Been there, saw it, ran away.

[diji1]

canman : Been there, saw it, ran away

that's certainly not the nicest thing i hear about everwicked's site, lol. i visit there often but am not a member yet - im pretty choosy though, so the fact that i visit it often means i think it's a pretty darn good site. it's certainly better than 99% of the rest of the other dvd backup websites imho ... we all know what the webs ultimate dvd conversion site atm is though, don't we :).

[canman]

No that wasn't nice, and it wasn't meant to be. I have read many of he's posts and while he might know a few things, he is extremely biased in all his opnionsm it's his way or the highway. That I do not like. Just take a look in this thread:

http://forums.divx.com/viewtopic.php?forum=16&topic=35441

[cofferscuffs]

Well he does prefer HeadAC3ache, which is the main opposition to BeSweet, but that doesnt give EW a reason to name his programm BeAhead as it is a personal shoot at DSPGuru.

But please, lets not take this thread into "I hate EverWicked" domains... as I would like to see how BeAhead develops.

[canman]

Oh, please, can't I? Oh well, I'll try and BeHave.

[Doom9]

my tests (in the thread above) show that besweet is faster, at least on my machine. Come to think of how both programs handle the data isn't not really surprising... hac3 writes a huge tempfile to your HD which stresses the I/O subsystem, besweet does a direct transcoding them uses a postgain engine to increase the volume whereas the gain is applied to the float wave file when encoding it to mp3. the slower your I/O subsystem is (and mine should be quite fast) the larger the speed difference will be (in besweet's favor).

[MaTTeR]

@everwicked

I told ya bEWicked would be more fitting:D

@canman

Your so kind and have such a great way with words:rolleyes:

[facts]

@everwicked
of course we'd like float mode, well i would at least, thanks.

[diji1]

i had decided that i would not post anything more to this thread but feel bad about some comments that i made ( regarding everwicked.com ) so im gonna :(. the long and the short of it is that after having a coupla things pointed out to me concerning everwicked by ppl that i respect i did some of my own reading on various public forums ... im not going to spell it out for everybody, you can all read and form you're own opinions about what is happening around here. based on my own conclusions i have decided that i will not patronise everwicked.com again. it's the principle of the thing for me but make up your own minds everybody ...

[llemor]

I did my own testing...BeSweet is faster than everwicked's BeAhead.

I think the program's name doesn't fit to its performance.:D

[MaTTeR]

@diji1

You should inform these "respected" people that the more they want to spread these stories whether it's fact or not is going to hurt this community IMHO. These stories and this issue seems to be growing and sooner or later it has the possibility to create a division. This will not be good for any of us or either site. So I have to question why these "respected memebers" would want to share this information with you. People have done that sort of thing with me in the past, now I can look back and see a hidden agenda and realize I didn't know all the facts and was just hearing one side of the story. It will be nice if and when this issue is banished so we can get back to the reason were actually here. I for one am not here to play childish games and I'm quite sure the _majority_ of the people here want no part of it either.

Disagree or flame me if you like, it's just my personal opinion.;)

Edit-
@llemor
As Doom9 stated in another thread to me, baseless claims are useless. Lets see the configuration and log files please.

[diji1]

no flames here ... :)

matter : "You should inform these "respected" people that the more they want to spread these stories whether it's fact or not is going to hurt this community IMHO."

i agree ... i really do. i have nothing against anybody as such - i just see things going on that seem a little unsporting. i really had no idea about any of it until a few days ago. there was no stories as such spread ( to me at least ) about this little affair, though it was a pm regarding this thread that made me curious about the whole thing. as i said, i drew my own conclusions from reading public forums though. i formed my opinion just on what i read. of course opinions were bandied about in pm's but i try to take them with a grain of salt really. i tried not to troll in that post, just to put across that i stuck up for something that i now wouldn't.

matter : People have done that sort of thing with me in the past, now I can look back and see a hidden agenda and realize I didn't know all the facts and was just hearing one side of the story.

there's no way i know everything about this little saga at all ... but i don't think i was privee to any private infomation really.

matter : I for one am not here to play childish games and I'm quite sure the _majority_ of the people here want no part of it either.

sorry if it seemed childish ( i agree with you ) - just seems hard to stand back and watch i guess.

matter : It will be nice if and when this issue is banished so we can get back to the reason were actually here.

well, that's goin to be the last post from me about it.

[llemor]

@ matter:

As per your request, here's the configuration:

My machine: P4 1.60A Ghz, Intel 845, 256 DDR memory, 25 GB free drive space during transcoding.

The Movie: Harry Potter - 152 min. & 21 sec., AC3 source file is demuxed with DVD2AVI.

BeAhead: Mode ABR, Min.bitrate=32, Max bitrate=320, Joint stereo, float mode (i guess faster than dumb mode as per documentation)

No saved log file, but after transcoding a message box pop-ups and showed 0:44:41 (44 min. & 41 sec.). This is the same time I calculated based on my computer's clock. I could not find saved log file, please tell me if any.


For BeSweet, here's the generated log file:BeSweet v1.3RC by DSPguru.
--------------------------
Using azid.dll v1.8 (b825) by Midas (midas@egon.gyaloglo.hu).
Using lame_enc.dll v1.28 (18/4/2002), Engine 3.92 <http://www.mp3dev.org/>.

Logging start : 06/02/02 , 18:25:01.

D:\DIVXAP~1\GORDIA~1\besweet.exe -core( -input D:\Movie1\Output\HarryPotter AC3 T01 3_2ch 448Kbps DELAY -83ms.ac3 -output D:\Movie1\Output\HarryPotter AC3 T01 3_2ch 448Kbps DELAY -83ms.mp3 -logfile D:\Movie1\Output\HarryPotter AC3 T01 3_2ch 448Kbps DELAY -83ms.log ) -ota( -G max ) -azid( -c normal ) -lame( -h --abr 128 --scale 1 ) -profile( Gordian Knot 0.26 )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : D:\Movie1\Output\HarryPotter AC3 T01 3_2ch 448Kbps DELAY -83ms.ac3
[00:00:00:000] | Output: D:\Movie1\Output\HarryPotter AC3 T01 3_2ch 448Kbps DELAY -83ms.mp3
[00:00:00:000] | Floating-Point Process: Yes
[00:00:00:000] +-------- AZID -------
[00:00:00:000] | Output Stereo mode: Dolby surround compatible
[00:00:00:000] | Total Gain: 0.0dB, Compression: Normal
[00:00:00:000] | LFE levels: To LR 0.0dB, To LFE 0.0dB
[00:00:00:000] | Center mix level: BSI
[00:00:00:000] | Surround mix level: BSI
[00:00:00:000] | Dialog normalization: No
[00:00:00:000] | Rear channels filtering: No
[00:00:00:000] | Source Sample-Rate: 48.0KHz
[00:00:00:000] +-------- LAME -------
[00:00:00:000] | Bitrate method : ABR
[00:00:00:000] | Avarege Bitrate : 128
[00:00:00:000] | MP3 Min bitrate : 32
[00:00:00:000] | MP3 Max bitrate : 320
[00:00:00:000] | Channels Mode : Joint Stereo
[00:00:00:000] | Error Protection: No
[00:00:00:000] +---------------------
[02:32:21:312] Gain of 13.5dB had been asserted to file.
[02:32:21:312] Conversion Completed !
[02:32:21:312] Actual Avg. Bitrate : 116kbps
[00:29:49:000] <-- Transcoding Duration
Logging ends : 06/02/02 , 18:54:50.

As you can see, the difference of transcoding durartion is about 15 minutes. Maybe different machine will give different result.

Btw, I have no other intention but to test the speed of both softwares. I used both of them because they are great programs.;)

[everwicked]

The reason of the test is to compare the performance of both transcoding programs using the same exactly settings and also compare their extra features. The test is concentrated on AC3 to MP3 since the performance argument between the two was only brought up after the release of BeAhead, a utility that allows the use of HeadAC3he instead of BeSweet when transcoding directly via Gordian Knot.

The software used for this test is BeSweet 1.3RC3 and HeadAC3he 0.23a2 (bundled with BeAhead) with the MMX libraries.

MMX Benchmark

System setup:
AMD Duron 800MHz overclocked at 1000MHz
128MB PC100 SDRAM
Asus A7V133 (KT133A)
Quantum Fireball 30GB UDMA 100 (2MB Cache)
Windows XP Pro

To perform the test I used the AC3 from the first VOB of the Final Fantasy DVD.

AC3 Statistics
Duration: 27:23
Size: 92,042,499 bytes
Frequency: 48kHz
Channel setup: 5.1
Bitrate: 448kbps

BeSweet settings
Azid: Auto find Max Gain
Dynamic compression: normal
LFE to LR: -3dB
Lame: Alt ABR Preset
Bitrate: 128kbps
Priority: Realtime

I added Auto Gain in the second test and Post Gain in the third test.

HeadAC3he settings
Running PTB that is bundled with HeadAC3he I found out the optimal Read/Write Block sizes.

The graphs below shows a graphical demonstration of the results.
http://www.everwicked.com/content/temp/readptb.gif
http://www.everwicked.com/content/temp/writeptb.gif

As you can see, reading speed peaks at 16KB Block Size while writing peaks at 32KB Block Size.

Lame Settings: Min bitrate 32
Average 128
Max 320
Alt ABR preset
Priorities: CPU: Highest
I/O: Highest
Note: I found that these priorities worked best for my system.

The first test was with float mode and Surround 2 downmix. The second test with Surround downmix while the third and fourth tests were with dumb mode. I used Surround 2 and Surround downmix in the third and fourth tests accordingly.

To run PTB and do the comparison I dedicated a 2GB FAT32 partition.,

The performance chart looks like this:
http://www.everwicked.com/content/temp/transcode.gif

SSE Benchmark

System setup:
Pentium III 850Mhz
512MB RAM
Soyo 6BA +III
1 30GB Maxtor 7200RPM (D Drive)
1 20GB Western Digital Fireball 7200RPM (C Drive)

Note: This benchmark was done by a friend over the Internet. I made sure he did everything right. However he didn't go through PTB and therefore better performance of HeadAC3he can be achieved.

AC3 Statistics
Duration: 12:02
Size: 40,444,992 bytes
Frequency: 48kHz
Channel setup: 5.1
Bitrate: 448kbps

The test was performed using the SSE libraries of HeadAC3he and we used only the two fastest modes of both programs.
HeadAC3he: Float Two-pass mode with DPL I
BeSweet: Post Gain

The image below talks by itself.
http://www.everwicked.com/content/temp/sse.gif

Comments
While BeSweet with Post Gain is faster than HeadAC3he in any case when using the MMX libs, HeadAC3he knocks back BeSweet with the SSE libraries of HeadAC3he (and the appropriate CPU)

All is not lost for people with CPUs that support MMX only, read below.

Why not Post Gain?
Many people think Post Gain is a great thing. And it is indeed, if you look at it speedwise at older CPUs. What about the quality though. Read on..

Whilst post gain itself doesn't imply a quality loss, the method hinders quality loss when used with particular PsychoAcoust models. One of these models is LAME like shown below.

The psycho model used here (this test only covers LAME) doesn't care for very low volume material, that's why it treats material with different gains
differently.

The test below shows my point even better.

I took the same AC3 file. I decoded it to 6channel 32bit float WAV with HeadAC3he using -110db gain. I encoded back to AC3 with SoftEncode. Default settings were used (448kbps bitrate).

Next I transcoded the latter AC3 with HeadAC3he in 2-pass mode (dumb/float doesn't matter it's the same qualitywise) and with BeSweet in all 2-pass mode (Normal/AutoGain/PostGain)

I provide the dir listing of the MP3s:

09/06/2002 03:38 μμ 24.688.800 -110Gain HeadAC3he.mp3
09/06/2002 03:57 μμ 6.575.168 -110Gain BS PostGain.mp3
09/06/2002 04:08 μμ 6.575.168 -110Gain BS AutoGain.mp3
09/06/2002 04:24 μμ 6.575.168 -110Gain BS Normal.mp3

Obviously enough 128kbps average bitrate was not achieved from either programs. However BeSweet averaged at 37kbps in all three modes.

When I opened the files in WinAmp, the experience was unique. Because of the -110db Gain of the original, there was a constant "noise". However, the file transcoded with HeadAC3he apart from noise preserved the dialogs and they were quite audible. On the other hand BeSweet only preserved the noise.

Opening the files in CoolEdit yielded:
http://www.everwicked.com/content/temp/cooledit-hac3.gif
http://www.everwicked.com/content/temp/cooledit-bs.gif

By this I have shown how dynamics are lost. The test initially was trying to prove that this is due to post-gain method/Lame's psycho accoustics. Surprisingly enough, this is the behaviour of BeSweet in all modes which made me sceptic about how it was optimised.

Conclusion
BeSweet with Post Gain certainly gives slightly better performance to your transcoding but it seems to accomplish this at the expense of quality.

After all I think it is a bad idea to sacrifice quality/dynamics for a small gain of speed. But that's just me, feel free to post your comments.

If you want to extend this, HeadAC3he nowadays supports Surround 2 downmix and is also worth noting is that HeadAC3he is optimized for specific CPU types (MMX, SSE and SSE2 libraries), which is also a reason why it knocks out BeSweet in the test with the P3 CPU. Furthermore Dual CPU owners will notice a nice speed boost due to some multi-threading and SSRC is somewhat optimized for dual CPUs as well. DarkAvenger is currently exploring other paths to optimize the overall speed. Keep in mind that HeadAc3he's speed is very I/O dependant. If your lucky enough to have a nice RAID setup then the speed up should be considerably faster. In general you should keep in mind that spreading I/O intesive applications across multiple drives should provide better performance as well (ie. read source from drive D while writing destination file to drive E).

Surround 2 Downmix Explained
Since a lot of people ignore what this feature is and Dark Avenger hasn't commented about it in his documentation, here it goes.

Surround 2 downmix is somewhat based around the new Dolby Pro Logic II which should provide a little better rear channel separation. The advatage of this downmix mode will be realized much more when using a Circle7 or DPLII amp but even with a regular Dolby ProLogic you should hear the difference.

So when doing a DS2 ("Surround 2") downmix, the rear channel will be seperated on decoding (of course not perfect, but nevertheless quite OK) which won't happen with a normal DS ("Surround") downmix. Even in pure stereo mode "Surround 2" gives you seperation of the rear channels (of course only on the stereo speakers) and Surround 2 is compatible to normal DPL.


BeAhead
I released BeAhead 0.2 after your requests.

Changes:
- Added README.txt
- Added switches


--mode float/dumb: Controls the Two-pass mode. If not specified, it defaults to dumb.

e.g. --mode float
The above switch will use float two-pass mode in HeadAC3he

--io idle/below/normal/above/highest/critical: This switch controls the I/O priority of HeadAC3he.

--cpu idle/below/normal/above/highest/critical: This switch controls the CPU priority of HeadAC3he.

Download at http://download.everwicked.com

These switches must be put in the LAME switches field of Gordian Knot.


Thank you, everwicked

[everwicked]

Originally posted by canman
Been there, saw it, ran away.

Flattered.

Originally posted by canman
No that wasn't nice, and it wasn't meant to be. I have read many of he's posts and while he might know a few things, he is extremely biased in all his opnionsm it's his way or the highway. That I do not like. Just take a look in this thread:

http://forums.divx.com/viewtopic.php?forum=16&topic=35441


There's the benchmarks, there's the setup. cYa

Originally posted by cofferscuffs
Well he does prefer HeadAC3ache, which is the main opposition to BeSweet, but that doesnt give EW a reason to name his programm BeAhead as it is a personal shoot at DSPGuru.


It never shot DSPGuru, I don't even know the guy. BeAhead is BeSweet+HeadAC3he by some means, therefore the name.

Originally posted by diji1
the long and the short of it is that after having a coupla things pointed out to me concerning everwicked by ppl that i respect i did some of my own reading on various public forums ...

I can only guess who pointed you "these things" but if you are interested to listen to some truths, my e-mail is everwicked@everwicked.com

Originally posted by llemor

BeAhead: Mode ABR, Min.bitrate=32, Max bitrate=320, Joint stereo, float mode (i guess faster than dumb mode as per documentation)


I wonder how is that possible, I just released BeAhead 0.2 with float mode support.

[llemor]

I run headAC3he without GKnot, that's why I can set it to float mode.
Is there any big difference if I set BeAhead switches inside GKnot environment?

[everwicked]

BeAhead: Mode ABR, Min.bitrate=32, Max bitrate=320, Joint stereo, float mode (i guess faster than dumb mode as per documentation)


You didn't make that clear.

No it doesn't make any difference. But you probably chose DPL2 (default) which is better and also slower.

[llemor]

You didn't make that clear.
BeAhead is obviously executing HeadAC3he to transcode audio, right? And you knew that HeadAC3he supports float mode, right again? Then, how come the setup I've mentioned is not clear?

Btw, what is DPL2?

[everwicked]

Originally posted by llemor

BeAhead is obviously executing HeadAC3he to transcode audio, right?

And you knew that HeadAC3he supports float mode, right again?

Then, how come the setup I've mentioned is not clear?

Btw, what is DPL2?

Yes.

Yes, but that it supports it doesn't mean it's the default. If you 've read my posts about BeAhead they say it uses "dumb mode" as the default.

So what you mentioned is not clear because you said "BeAhead: I used float". That would not be possible and the statement is not the same with "HeadAC3he: I used float" which is the right one.

I hope you get my point.

DPL2 is the Surround 2 downmix mode, read above to see what it is..

[llemor]

Okay, I understood what you meant 'not clear'.

Oh, I see DPL2 means Dolby Pro Logic II. I can't remember which downmix type I've selected during testing but as I remember I did the setting similar to BeSweet.

Anyway, I'll give a try again and hopefully HeadAC3he will give its best. :) And don't get me wrong everwicked, I'm not pro-BeSweet nor HeadAC3he-hater. I love them both. :D

Btw, is there a way to save the log file generated by HeadAC3he?

[everwicked]

Originally posted by llemor
Anyway, I'll give a try again and hopefully HeadAC3he will give its best. :) And don't get me wrong everwicked, I'm not pro-BeSweet nor HeadAC3he-hater. I love them both. :D

Btw, is there a way to save the log file generated by HeadAC3he?

Me either, I am not arguing here.

Uhm.. I don't think there is a way to save the log but its log console doesn't print any useful info really.

Btw, make sure you use the SSE2 libs since u got a PIV and DPL I

[DSPguru]

at first i thought i shouldn't bother replying to this thread..
after all, no-one but llemor even bothered replying to it.
people here experienced with BeSweet, they read my posts daily & familier with my work.

but now i'm in a very good mood :), so i thought i'll give a nice pre-reply.

here it is :

@everwicked
either you are soooooooooooo unbelivebly stupid to believe in your test and your conclusions, or that you so hate me and envy with the fact that the all important tools are being developed by the moderators of this most-popular website, that you don't have any problem with humiliating yourself over few boards (i know of at least 3 instances of your post in 3 differenct boards) and making a complete fool of yourself, making you look like the greenest newbie on earth.


before we start, an appetizing question :
why didn't you post your test results over hydrogenaudio forum where all the audio developers hang around ?


take care :D !
Dg.

[Charlieds]

@DG
:D ;)

@EW
BeLessBoring.

[Doom9]

@everwicked: it's rather interesting to see that the sse results you've posted are completely different from my own (http://forums.divx.com/viewtopic.php?topic=35441&forum=16)... It would be even more interesting to hear what happens if your friend replaces the regular besweet dlls with the see optimized ones from headac3he.. encoding in besweet should theoretically also be faster since the dlls would be the same and post gain is less I/O demanding.

as for quality.. that is a very delicate issue.. I still remember the controversy that mp3 test in CT has caused and I wouldn't want to see anything similar on this board. I feel confident judging visual quality, but when it comes to audio I'm much less confident so I doubt I'd be hearing much of a difference doing a one on one comparison at the same bitrate and settings. I'm also not very much into DSP matters, in fact I hated that class in college and I consider myself lucky to have passed it. However, I don't recall ever having to apply a gain that would counter your -110dB.. in fact I think I've never gotten above a 20dB gain even. So I have my doubts that this particular test is saying us anything useful. Imho it would make much more sense to actually compare the output you'd be getting by both programs in a regular encoding scenario where you let hac3's and besweet's gain engine find the best gain.

[everwicked]

Originally posted by DSPguru
but now i'm in a very good mood :), so i thought i'll give a nice pre-reply.

here it is :

@everwicked
either you are soooooooooooo unbelivebly stupid to believe in your test and your conclusions, or that you so hate me and envy with the fact that the all important tools are being developed by the moderators of this most-popular website, that you don't have any problem with humiliating yourself over few boards (i know of at least 3 instances of your post in 3 differenct boards) and making a complete fool of yourself, making you look like the greenest newbie on earth.

before we start, an appetizing question :
why didn't you post your test results over hydrogenaudio forum where all the audio developers hang around ?


Actually it was mirrored at my website: http://www.everwicked.com/forums/showthread.php?s=&threadid=1096
and as a reply to thekid's question and Doom9's tests here: http://forums.divx.com/viewtopic.php?topic=35441&forum=16 and the third one is here, yet again as a response.

I was only replying to other posts, there was no point posting this out of nowhere, that is why I made it a forum post and not a review at my website. Perhaps you could explain to all of us why this test is stupid or invalid?

Originally posted by Doom9
@everwicked: it's rather interesting to see that the sse results you've posted are completely different from my own (http://forums.divx.com/viewtopic.php?topic=35441&forum=16)... It would be even more interesting to hear what happens if your friend replaces the regular besweet dlls with the see optimized ones from headac3he.. encoding in besweet should theoretically also be faster since the dlls would be the same and post gain is less I/O demanding.

as for quality.. that is a very delicate issue.. I still remember the controversy that mp3 test in CT has caused and I wouldn't want to see anything similar on this board. I feel confident judging visual quality, but when it comes to audio I'm much less confident so I doubt I'd be hearing much of a difference doing a one on one comparison at the same bitrate and settings. I'm also not very much into DSP matters, in fact I hated that class in college and I consider myself lucky to have passed it. However, I don't recall ever having to apply a gain that would counter your -110dB.. in fact I think I've never gotten above a 20dB gain even. So I have my doubts that this particular test is saying us anything useful. Imho it would make much more sense to actually compare the output you'd be getting by both programs in a regular encoding scenario where you let hac3's and besweet's gain engine find the best gain.

You used the normal priorities (as you didn't mention anything). You also did not tell what was the 2-pass mode of your last test.

DG could try compiling his libraries for SSE, it's just a couple of switches in the project but speed is not my only concern.

I explain why I applied the -110db and what I proved. The rest are in my post above.

[pacohaas]

how about, instead of all this controversy, we just offer the 2 versions of GKnot, until some sort of GKnot option appears allowing the user to choose HeadAC3he or BeSweet. I mean, is this really worth 33 replies? It seems there are loyalties here, but that shouldn't be the issue, the issue is choice, everwicked(any hidden-agenda's aside) is simply offering GKnot users a choice. period.

I'm not saying he has any hidden-agenda's and even if he does, who cares?

Can't we all just get along? :angry: :rolleyes: :scared:

[MaTTeR]

Well said pacohaas, choice is always good for all of us. I seriously doubt TheWef would come out with a new version to support both apps but then again he has suprised us before:)

Uhmm..I'm not sure I understand the gain test performed but I have to admit it does sound quiet interesting(no pun intended :) )and it's hard to dismiss this easily at least without hearing why the dramtic file size differences are appearing. Remember not all of us are engineering gurus like a few of you here.

@Everwicked
Did you by chance happen to use the -scale1 switch with post gain? It appears the BeSweet GUI is having it set by default for some reason(never noticed that before, maybe it's the b49 version I have). It's been awhile since I read about this LAME feature but at last read I thought it wasn't advised to use it just yet for best possible quality. Can anyone clarify why we should use this feature?

Hope I'm not the only soul around here who realizes that you need to read the source file(AC3) from 1 drive and save the destination file to another in order to see best performance.

Also, why the MP3 benchmarks? Vorbis benchmarks would be much more appealing:)

PS. Perhaps this thread belongs in the audio forum now? Amazing all the excitement a person can miss after going to work:)

Edit- Everwicked brings up something, why not have SSE or SSE2 builds for BeSweet that are optimized ICL6 compiled? To go a step further, I hope some of you are taking note how many users here have SMP boxes these days:D I need to form a little SMP group so we can help develop some true multi-threaded SMP aware apps. hehe

[DSPguru]

Originally posted by everwicked
Perhaps you could explain to all of us why this test is stupid or invalid?
maybe we should start with asking :
a. why do you think that your test means anything ?
b. was it really you behind this test ?
hint, post from 28th February :
http://forum.doom9.org/showthread.php?s=&threadid=27008

[DarkAvenger]

Dear everwicked,

don't waste your energy on arguing with people who are incapable of and rather like spilling out propaganda and doing marketing with more or less false statements. I learnt it the hard way and now I know it is better to simply ignore. Intelligent people who can read and think will understand your test and what you wanted to show. Unfortunately there are enough people who rather like believing propaganda, but it is their problem and not mine. So let the average user use their mainstream tool, as the elites know what they need to get best quality and efficiency. Dead simple.

But it is interesting that Dg points at a posting where the whole beginning has disappeared and has a new topic [EDIT: Thinking again, I dunno if it is the original topic name, but I at least cannot find the prior postings to it...] (which shows Dg in a bad light, btw., the missing beginning and the manipulation (->propaganda) as such...). Nevertheless he doesn't seem to understand the difference of that post and above test, as something different was to be proven (and has been), though a similar test was applied. At least it would made me think why normal normalization yields to the same substandard quality as post gain. A really unexpected result.

[What is even funnier are statements like "first floiting point tool" or alike if this tool used short input for mp2enc and short output for mpglib for months and months, while other tools directly used modifed versions of that libs with floating point input/output weeks before the other tool switched to floating point.]

OK, enough of that. Mir hängts echt zum Halse raus.

Keep your eyes open and your mind thinking....

[DSPguru]

speed
i'm not planning to write a lot about the speed comparison, because :
1. you all saw other test results that showed the opposite.
2. everyone can make a simple test at home, and judge best for themselves.

what i do find important saying about this issue, is that everwicked's graphes are misleading, by (intentionly) jumping around between 3 different normalizing methods that offered by BeSweet.

Originally posted by everwicked
BeSweet settings
Azid: Auto find Max Gain
Dynamic compression: normal
LFE to LR: -3dB
Lame: Alt ABR Preset
Bitrate: 128kbps
Priority: Realtime

I added Auto Gain in the second test and Post Gain in the third test.if you've read my own posts about those 3 normalizing methods, you could see that i wrote that PostGain is faster than Max Gain that is faster than Auto Gain.
So, I doubt the whole test until i at least see some relevant logfiles.

not to mention that lame compiles (sse/mmx) got nothing to do with speed of BeSweet vs. Headac3e.

'nough said! (just test for yourself).


quality
here i will try to clarify some stuff without getting too technical, hoping that most of the people can understand.
apologies for those who failed.

Originally posted by everwicked
Why not Post Gain?
Whilst post gain itself doesn't imply a quality loss, the method hinders quality loss when used with particular PsychoAcoust models. One of these models is LAME like shown below.

The psycho model used here (this test only covers LAME) doesn't care for very low volume material, that's why it treats material with different gains
differently.BeSweet is using 24bits to represent the mantissa of all audio samples decoded by azid. now, even if you don't assert any gain to your signal before delivering it to lame, and assuming the maximal gain should have been 24dB (that’s a very high value, as you all know), that means that, effectively, only 20bits were used to represent the source signal.
needless to say that most soundcards can only reproduce signal using a 16bit d/a chips. so 20bits are more than enough!
but what about those people who did buy 24bit soundcards ?
as some of you might know, thanks to my work (http://www.geocrawler.com/lists/3/SourceForge/7323/0/7383462/) from last year on creating floating-point interface to lame's dll, the original accuracy of 24bits wouldn't be affected by not asserting the 24dB gain, simply because it will only affect the other 8bits in the floating-point register that represents the exponent.

now for that bullshit about lame's "particular psychoacoustic model" (there's more than one, btw),
lame uses psychoacoustic models in order to omit "irrelevant" signals by taking advantage of 2 (or even 3?) types of masking effects, and then implements a dynamic bit allocation on the mdct coefficients.
in addition, signals below the aboslute threshold of hearing (aka ATH) are also being omitted.
the deficiency of this method is that ATH are being referenced to what you call 0dbSPL ("absolute"), while 0dbSPL is not known to the encoder (can only be known at the end of the encoding process), and have to use some assumptions on its value or on how to find it.
when inputting a rather low-volume signals to the this kind of encoder, it might wrongly find that important parts of the signal are below ATH, and then omit it.
on the other hand, normalizing the signal prior to encoding it, can lead to even a worse phenomenon. not only that non-relevant signals would be coded, and therefore leaving less available bits for the do-important signals (poor bit allocation), you might find yourself with clippings! (there's a noticeable clip in the cooledit capture of headac3e (http://www.everwicked.com/content/temp/cooledit-hac3.gif) that doesn't clip on BeSweet (http://www.everwicked.com/content/temp/cooledit-bs.gif)).

now, if you consider yourself an advanced user, you could see that my advised commandline for ac3->mp3 transcoding (supplied within BeSweetGUI's built-in profiles), is :
DSPguru_mp3@128kbps=-azid( -n1 -c normal -g 10db -L -3db ) -ota( -G max ) -lame( --scale 1 --alt-preset 128 )
this implements a hybrid gain assertion, and should be using all the advantages of each method.
the combination of dialog normalization together with a static 10db gain gives you a very fair chance that important signals won't find themselves below ath, and still truely low signals shouldn't be encoded.
the usage of BeSweet's PostGain together with scale=1, will gurantee you that your track, even though encoded with low volume (gain<max), will be playbacked on your soundcard when peak=Vfullscale, or in simple words : all the 16bits (or even 24bits) of the D/A's resolution will take a role in reproducing your encoded track. (not to mention that you won't need to raise up the volume of your analog reciever too much, and that gives you relatively less 'hiss' & 'humm' sounds).

you might also want to read this short thread :
http://www.hydrogenaudio.org/forums/showthread.php?s=&threadid=587

Originally posted by everwicked
The test below shows my point even better.

I took the same AC3 file. I decoded it to 6channel 32bit float WAV with HeadAC3he using -110db gain. I encoded back to AC3 with SoftEncode. Default settings were used (448kbps bitrate).

Next I transcoded the latter AC3 with HeadAC3he in 2-pass mode (dumb/float doesn't matter it's the same qualitywise) and with BeSweet in all 2-pass mode (Normal/AutoGain/PostGain)

When I opened the files in WinAmp, the experience was unique. Because of the -110db Gain of the original, there was a constant "noise". However, the file transcoded with HeadAC3he apart from noise preserved the dialogs and they were quite audible. On the other hand BeSweet only preserved the noise.the -110db test pushes the whole signal below ATH and it's nonrelevant to anything you would expect from an AC3 you'll find in any DVD.
with the same style of this misleading test, i could be doing the very same process but with only positive gain of +110db. this time the whole signal would be pushed beyond the maximal value and we'd end up with an extremly-distorted track. (i could also attach some ugly CoolEdit capture that shows this. but that's your style. not mine).

now, the most hilarious thing about ew's public test is the fact that he found that BeSweet simply encoded noise out of his 32bit fp wav file.
hmmm... and didn't you know that BeSweet only supports 16bit wav files ? don't you read before reoprting bugs.. ?
needless to say that 32bitfp wav=16bit noise wav.

not to mention that only a newbie could come up with the idea of comparing quality of BeSweet vs. headAC3e with different dll versions and compilations of the lame encoder.

Originally posted by everwicked
Opening the files in CoolEdit yielded:another thing you should know :Originally posted by tangent
Graphs say nothing about audio encoding quality. Nothing beats the ear. Graphs can be used to study the effects of encoding, but cannot be used to make conclusions on quality.the only thing i've learnt from this capture is that a 150kbps mp3 looks different than a 136kbps mp3.

Originally posted by everwicked
By this I have shown how dynamics are lost. The test initially was trying to prove that this is due to post-gain method/Lame's psycho accoustics. Surprisingly enough, this is the behaviour of BeSweet in all modes which made me sceptic about how it was optimised.so now you say that BeSweet delivers the same quality with all Gain modes. doesn’t this conflict with all your earlier analysis ?

Originally posted by everwicked
Conclusion
BeSweet with Post Gain certainly gives slightly better performance to your transcoding but it seems to accomplish this at the expense of quality.

After all I think it is a bad idea to sacrifice quality/dynamics for a small gain of speed. But that's just me, feel free to post your comments.everyone knows that while I focus on developing more and more DSP plugins for BeSweet (I was the one to develop ssrc.dll (http://forum.doom9.org/showthread.php?s=&threadid=11179), AC3ENC.dll (http://www.hydrogenaudio.org/forums/showthread.php?s=&threadid=2215)), DA is focusing on increasing the speed of his tool. If you don’t care much about speed, why did you came up with behead ? : Originally posted by everwicked
I cannot provide numbers but I can tell you this. When BeSweet was integrated in Gordian Knot, people were complaining about speed. I have still to see someone complaining about HeadAC3he.

i believe people are pretty much amazed with how much time and eregies you're putting on bringing mess and disputes to this board.
if i had all the free time you have, and had put all the time you had put on flaming me in public, in development, you could be using BeSweet today for transcoding DTS->AAC.


i know DA's work. and it's fine by me that some people loves HeadAC3e more than my tool.
question is, mr. wicked, what was your contribution to divx community ?

Dg.

[everwicked]

Originally posted by pacohaas
I'm not saying he has any hidden-agenda's and even if he does, who cares?


I don't know if DSPGuru's first reply gave you that impression but actually I don't have anything hidden here. If you look back a few months, I was offering a host to DA but we split up in the end because people thought the whole website was biased into HeadAC3he. I will not name "people" but you get the idea. I will not dig up the reason I firstly used HeadAC3he that goes very back in time and it really has nothing to do. It worths noting that when I sent a PM to DSPGuru about this anti-BeSweet conspiracy hype he never got back to me nor he showed up at my forums. Who has the hidden agenda now?

Originally posted by MaTTeR
@Everwicked
Did you by chance happen to use the -scale1 switch with post gain? It appears the BeSweet GUI is having it set by default for some reason(never noticed that before, maybe it's the b49 version I have). It's been awhile since I read about this LAME feature but at last read I thought it wasn't advised to use it just yet for best possible quality. Can anyone clarify why we should use this feature?

Also, why the MP3 benchmarks? Vorbis benchmarks would be much more appealing:)


No I didn't, I am aware that HeadAC3he doesn't use it to start with so I wanted to make things equal for both programs. I am also aware that its use was never recommended, at least for AC3 transcoding.

MP3 benchmarks because Gordian Knot cannot handle Vorbis. Same reason that I didn't add Vorbis support to BeAhead.

Originally posted by DSPguru

maybe we should start with asking :
a. why do you think that your test means anything ?
b. was it really you behind this test ?
hint, post from 28th February :
http://forum.doom9.org/showthread.php?s=&threadid=27008

One can simply scroll up and look for the already answered questions.

I wonder what happened to the previous posts in that thread.

Originally posted by DarkAvenger
Intelligent people who can read and think will understand your test and what you wanted to show. Unfortunately there are enough people who rather like believing propaganda, but it is their problem and not mine. So let the average user use their mainstream tool, as the elites know what they need to get best quality and efficiency. Dead simple.

But it is interesting that Dg points at a posting where the whole beginning has disappeared and has a new topic [EDIT: Thinking again, I dunno if it is the original topic name, but I at least cannot find the prior postings to it...] (which shows Dg in a bad light, btw., the missing beginning and the manipulation (->propaganda) as such...). Nevertheless he doesn't seem to understand the difference of that post and above test, as something different was to be proven (and has been), though a similar test was applied. At least it would made me think why normal normalization yields to the same substandard quality as post gain. A really unexpected result.

Keep your eyes open and your mind thinking....

I chose just to repeat some of Dark Avenger's words instead of replying to him.

[DarkAvenger]

Wow, the first time since months (or years?) there is a at least partial useful posting from Dg, which deserves a more serious reply. :D


not to mention that lame compiles (sse/mmx) got nothing to do with speed of BeSweet vs. Headac3e.


Well, yes that is true if you really want to nail down speed on the core. BTW, it is called HeadAC3he.


the deficiency of this method is that ATH are being referenced to what you call 0dbSPL ("absolute"), while 0dbSPL is not known to the encoder (can only be known at the end of the encoding process), and have to use some assumptions on its value or on how to find it.
when inputting a rather low-volume signals to the this kind of encoder, it might wrongly find that important parts of the signal are below ATH, and then omit it.


Absolutely and here is the problem: According to my tests Lame doesn't really try to find 0dbSPL. Why? Because it has been optimized for CDDA, ie. 44kHz 16bit stereo. So here we know that 0dbSPL=-96db (ok it is not true. Mr. Frank Klemm lately wrote the true formula in one thread at HA. The true value is something about (i forgot that number) -110db(+-2db) due to dithering I guess. But we can here just asume that 1bit gives you 6db SNR.) So with integer input we can have our ATH fixed and don't have to care how to scale/shift it. (There won't be anything below -96db, so why care for it?) Well and here the problem arises: Since we now have a float input the damn ATH still thinks it is 16bit int input, it throws everything away below -96db. (a)

So because of (a) inputing non-normalized material will result in loose of "bits". (Of course as the ATH is doing it, no real bits are lost, but low sounds will be discarded, anyway.)


on the other hand, normalizing the signal prior to encoding it, can lead to even a worse phenomenon. not only that non-relevant signals would be coded, and therefore leaving less available bits for the do-important signals (poor bit allocation),


Sorry, but I haven't heard less ridiculous than this a long time. You recommend not to normalize?!?
Our AC3 input has (according to Midas) at least 18bit per track, so downmixed and DRCed it will probably exactly fit into the 16bit window. So if you do *not* normalize it means that the last bits will fall under the ATH beacuse of my postulation (a) and thus you loose signals. I don't think the encoder is that bad so that we have to pre-filter out signals so that it knows what is dominant and what not...

you might find yourself with clippings! (there's a noticeable clip in the cooledit capture of headac3e that doesn't clip on BeSweet).


Mr. Dg maybe you forgot to wipe your glasses, but take a look at the graph again. (I guess you refer to the peak at about 8:00.)

a) The white line is -32k and NOT -32K. (Do you see/understand the difference?)
b) The peak doesn't even touch that line. Even if it did, due to a) it is still not clipping.
c) [Even if it did hit -32K - what is not the case] Due to the zoom level it is *impossible* to determine if it is clipping.
d) Even in close up zoom with samples visible, you can *never* say with 100% security that if something looks like clipping (touches +-32K) that it is clipping. It can also be 100% normalization.

But nice that you hint at this. As you can see HeadAC3he produces much louder output w/o clipping than BeSweet in post-gain mode (or whatever mode it is). So (to quote yourself):


all the 16bits (or even 24bits) of the D/A's resolution will take a role in reproducing your encoded track. (not to mention that you won't need to raise up the volume of your analog reciever too much, and that gives you relatively less 'hiss' & 'humm' sounds).


DSPguru_mp3@128kbps=-azid( -n1 -c normal -g 10db -L -3db ) -ota( -G max ) -lame( --scale 1 --alt-preset 128 )


In fact on the first sight it looks like a good compromise (and maybe it really is), but nevertheless it leaves a bad taste:

a) Well there is still something left of (a), though with 10db gain it is made less.
b) What if a track indeed will clip with that gain, or rather give you values >1. I dunno if Lame can cope with it without problems. Even if "clipping" is not the problem, to quote yourself (with normalizing you probably meant positive gain, which does more bad than good, so it applies to this situation, as well): not only that non-relevant signals would be coded, and therefore leaving less available bits for the do-important signals (poor bit allocation),


So in the end we have a compromise switch which results in rel. good speed. But on the other hand (with a good I/O) float mode of HeadAC3he can nearly compete with post gain mode and is a *secure* mode. So why take the risk?




now, the most hilarious thing about ew's public test is the fact that he found that BeSweet simply encoded noise out of his 32bit fp wav file.
hmmm... and didn't you know that BeSweet only supports 16bit wav files ? don't you read before reoprting bugs.. ?
needless to say that 32bitfp wav=16bit noise wav.


Mr Dg, again. I think there is something seriously wrong with your glasses. The only programme which had to deal with the WAV file was SFSE. BeSweet and HAC3 (nice abbrev, I guess.) only were fed with a AC3 made out of that WAV.


not to mention that only a newbie could come up with the idea of comparing quality of BeSweet vs. headAC3e with different dll versions and compilations of the lame encoder.


Well, admitted, to truly check speed against each other, we need identical compiles of the lib. But in this situation it speaks against you: As we see BeSweet delivers worse quality. So if it is not done in the source, it must be due to compilation and usually this happens due to aggressive optimization (eg. in ICL it is possible to reduce float /- calc precision). So *if* this was the case than it once again means that it was speed in sacrifice for quality.


quality.the only thing i've learnt from this capture is that a 150kbps mp3 looks different than a 136kbps mp3.


Huh? I have not seen these numbers in above test. Are we talking about the same one?

DA is focusing on increasing the speed of his tool.

Yes, that is why I implemented DS2 which gives me a performance drop for the sake of quality. :rolleyes: That's why HeadAC3he.exe is still a MSVC6 compile as (unlike with the libs which are tested as ICL compiles by a whole lot of people esp at ha) I don't know how ICL will negatively effect it, so I don't take the risk. Maybe you did, as we might see above.


Oh and if you can read German, you can take a look at http://www.dvdboard.de/forum/showthread.php?threadid=33935
where some German giys did some very successful tests with the DS2 downmix on DPL2/Logic7 amps.


question is, mr. wicked, what was your contribution to divx community ?

I'd say an alternative point of view is always good instead of being a lemming...


[a bit OT; not intended as flame bait but following really pisses me off, and possibly not only me, so think about it]


Did you notice that you like talking about how much you did for this and for that and bla bla here and bla bla there? What has it to do with all this? Do I always say that I was the one who told people how to make Dolby Surround mixes and using DRC (DSEnc)? Do I always say that I was the one who found a good modified matrix for DS2, which I made public btw? (I am only praising that HAC3 has that feature, but not stressing on my person...) And so on and so forth...

What is your problem Mr. Dg? For someone who stated something like, the people don't matter, science only matters, you give pretty much importance to yourself....(not even mentioning the fact that neither BeSweet nor HeadAC3he have much to do with science.)
I don't see much sense in putting "DarkAvenger" in my modified sources other than as short comment unlike you like putting your nick as #define and whatever.... :rolleyes:

God-complex? But I think God doesn't need glasses. :D


Another thing which came more precisely into my mind regarding "* BeSweet is the first tool to offer full-floating-point audio processing, reaching the highest quality possible !"

BeSweet (or whatever it was called that time) is the first tool to offer full-floating-point audio processing on AC3->MP3 conversion.
HeadAC3he is the first tool to offer full-floating-point audio processing on AC3->Vorbis conversion.
HeadAC3he is the first tool to offer full-floating-point audio processing on AC3->MP2 conversion.
HeadAC3he is the first tool to offer full-floating-point audio processing on MP2->whatever conversion.
HeadAC3he is the first tool to offer full-floating-point audio processing on MP3->whatever conversion.
HeadAC3he is the first tool to offer full-floating-point audio processing on 32bit float WAV->whatever conversion.

Did I forget anything? :D

And since I am not that marketing type I don't have to make marketing (esp false) statements on my website. I expect the people to know what the get, when they use HeadAC3he, because if I add a feature, I try to do it best possible and not add as much features as possible and maybe later doing it correctly...(usual unplanned bugs taken aside)
Well at least that "2Lame" lie was modified into "MP2enc".... But still that mythological "one-pass normalization". Ts ts ts...


Please explain to me: WHAT DO YOU GAIN BY ALL THIS?
[/OT]

[Doom9]

@dark avenger & everwicked: I invite you or anyone else to find me an AC3 taken from any DVD movie where you can here the effects that both DSPGuru and DarkAvenger have explained. Because what we have so far is the explanation of the test results.. but it's a result obtained in an extreme case. You certainly will never want to apply a gain of -110dB to your AC3 file.. In order to make a conclusion whether lame's ath cutoff really has an audible effect we would need a realistic example. I'm not watching the gains applied to my audio files very closely but I'm sure that I've never even gotten close to 100dB.. a value significantly larger than 20dB would already be rather extraordinary.

[DSPguru]

i have been told that people have became tired of this thread, and was advised not to reply.
but there are still a thing or two i want to say. will make it short!


judging by DA's post, it's obvious that DA knew that his -110db test would lead to bogus results, and as we can see now, he doesn't let reality standing in his way. in fact i also recall two times when bobotns and tangent told him that this argument is simply not valid.

do you really want me to show everybody what happens to headac3he when i use +100db gain ?
or maybe you think that it's simply nonrelevant.

further more, let's assume for a minute that your argument is valid and that one of every 1000 dvds suffers from this problem.
that means that everyone in this forum, in the worst case scenario would suffer from this property ONCE, and would sadly have to re-encode his audio using two-pass.
ONCE !
now, how valid does it makes your test ?!


Originally posted by tangent
Personally, I think you should by default override the --alt-preset's --scale. If a user uses pre-encode normalisation, then it would be silly to do another --scale in LAME. If a user uses post-gain, then --scale is useless. Either way, --scale should not be used.
the main reason that darkavenger & everwicked doesn't suggest using --scale 1 and PostGain is simply because headac3he doesn't offer it.
- lame's dll doesn't supply control on scaling, and i had to create my own lame_enc.dll in order to offer this in BeSweet (that's why it's the only transcoding program that lets you control lame's scaling,ath,psytunes,block types,'etc'..)
- in order to offer PostGain in headac3he, da would need to take mp3gain sources (http://www.hydrogenaudio.org/forums/showthread.php?s=&threadid=1225) and create an external dll for his proggy, i guess that takes time. (btw, i implemented the PostGain engine by myself. the MP3Gain sources became public after BeSweet's feature was already public).

once again, i have a different style.
i won't undermine cool features that aren't offered by BeSweet, therefore i have no problem in saying that i find HeadAC3he's Dolby Sorrund 2 support a nice feature.


about floating-point issue - i lead the way !
it's well known that i came up with the idea & first implementation. in fact, my patches were adopted by both official lame_enc.dll & mp2enc.dll.
vorbis library is originally processing floating-point samples, so there were nothing to do here.
as for fp of mpglib, i'm still holding its release ;)
from that day i firstly introduced my patches, standard quality for transcoded films have changed forever. suddenly, our community could preserve a full floating-point process for ac3 & ssrc & lame.
ask dvd2svcd users about their opinion about their audio quality since BeSweet was adopted to replace the old method.
ask all the GKnot users who used BeSweet seperatly and were waiting for the BeSweet integration.


reading closely da's last post reveals that everwicked's objective test between BeSweet and HeadAC3he, was actually made by HeadAC3he's author.
time for your conclusions.

[DarkAvenger]

I didn't make the test. EW just ask me how to actually show the differnce of post gain and real norm. So I gave an idea. nothing more. Nevertheless one shgould expect the same quality form HeadAC3he and BeSweet in normal mode in that situation. As it is not the case, I am asking myself, what is wrong. As you two don't understand or don't want to understand, I won't waste my time anymore.

[Doom9]

still waiting for that sample file taken from an actual movie without performing any manipulation on it, that when encoded in BeSweet using postgain will give me an audibly worse result than using HeadAC3he. If you think that is no valid request... well.. everybody is entitled to his/her own opinion...

It's just that this reminds me of the iDCT discussion that we had a long time ago... there again we had proof that certain algorithms were superior to others, but in a reasonable applicatoin scenario there wasn't a visible difference.

[DarkAvenger]

Aha, slowly you understand it. I didn't say it will be easy to *hear* the difference. Most (maybe 99,99%) it will not be, but there is a difference....

[cofferscuffs]

if theres a small difference... whats the point of this arguement?

[canman]

Originally posted by DarkAvenger
Aha, slowly you understand it. I didn't say it will be easy to *hear* the difference. Most (maybe 99,99%) it will not be, but there is a difference.... Ahh, so good of you to admit that you are infact the stupid one, how nice. I mean, you just agreed that postgain is in 99.99% the way to go :sly:

I am so happy that you (DA) decided to move on to EW's forum. You two seem to be such a !good team. I do remember how you behaved on the old EZBoard.

I know, I know, this is a flame post, but seeing two of the people which I loathe the most in the same thread, well I couldn't resist.

[Doom9]

@canman: I hope you're aware of the forum rules, especially rule4.. people can get suspended faster than they can make 3 posts :devil:

[DarkAvenger]

@canman

Hihi, what can someone reply to such a post? :p

[MaTTeR]

lol...canman seems to have either some sort of agenda or is an unhappy human being.

How about this? Let's say for the sake of argument that the average user won't hear the difference between the 2 transcoders. What does that leave you then? If it were me then I'd use whichever is fastest, most stable and easiest to use. Some people won't hear a quality difference because they are playing these tracks out of a cheap set of PC speakers and they aren't even sure what sort of artifacts to listen for. The above comment is only valid when we discuss LAME encoding. Do a listening test with Vorbis and you might find yourself in a different ballgame, at least that is my experience. That might be a mute point since most are still using LAME though.

@DA and Dg

Thanks for the explinations though, I followed most but not all of it:p Maybe I'll find some time to dig into -scale1 later this weekend and enlighten myself.

[canman]

Originally posted by MaTTeR
lol...canman seems to have either some sort of agenda or is an unhappy human being.Agenda, nope, unhappy yes sometimes, happy most of the time. But, my problem with the two above personalities actually did start way back on EZBoard. I always found that DA was baselessly attacking everything that didn't follow his way of thinking (especially in regards to DSPGuru), then along came EW. His way of BeHaving is quite similar to DA's and I just saw red and I couldn't shut up. Now I have been striken so I better stop here before I get striken again. I better leave this thread alone.

So long and thanks for all the fish.

[DarkAvenger]

Ok, let me put it this way:

If you are only interested in the fastest way to transcode with a good output, you can safely use BeSweet even in post-gain mode. (I never sad it produced bad output. According to the test it just failed the worst case, though I only expected that behaviour in post-gain mode.) But if you're interested in preserving as much of the original details and dynamics, there currently seems only be one way... Of coure one could ask oneself, whether mp3 as such is a good idea as target...

This should be the conclusion of the test - as far as it concerns me.

SO and now I'll unsubcribe to this thread. I already wasted much more time than it was worth it.

@matter

-scale 1 only overides Dibrom's scale parameters for ABR mode,AFAIK.

[MaTTeR]

@DA

Over-riding a default scale from "Dibrom" is NOT an option for me:D This guy obviously knows his shi*, otherwise we wouldn't have the --alt presets right now.

Thanks again!!

[Fox Mulder]

There is nothing wrong in overriding the scale in alt-preset xxx in regards to quality(told by Dibrom). You can use MP3Gain after the encoding and apply "Max Noclip Gain".
http://www.hydrogenaudio.org/forums/showthread.php?s=&postid=20145#post20145

[tangent]

I got an email/PM from Doom9 asking for "third party comments" in this thread because I'm "famailiar with lame and mp3gain". Okay, first a disclaimer: My experience is mostly with encoding of audio from music CDs, and not from movie soundtracks, and have been mostly involved with pure audio encoding communities of the nearly dead http://www.r3mix.net and http://www.hydrogenaudio.org , coming in to this forum occasionally to offer my opinions, comments and help. In most cases, movie-audio and music-audio encoding are similar, but there are also some differences. Most music people have never heard of BeSweet or HeadAc3he, most movie people have never heard of mp3gain, etc.


1. Regarding my own usage preferences

I use HeadAc3he when transcoding to Ogg Vorbis and BeSweet when transcoding to MP3. Since I mostly transcode to Ogg Vorbis, I use HeadAc3he most of the time. This is mainly because HeadAc3he provides faster transcoding using pre-gain method, and post-gain is not available for Ogg Vorbis transcoding.


2. Regarding "who wrote what first"

Personally, I don't really care about this issue and I suspect neither do most people, and I find it really silly that this issue would never need to be brought up. People, including myself, will simply use the better tool to get things done and not care about which one was written first. I do, however, appreciate the work done by the developers and understand the pride they will have in the work they did, and so do most of the users. But there is really no need to bring up this issue. Personally I'm dissapointed that neither developers have chosen to open-source their projects. I understand they have their reasons for not doing so, but I'm hoping on the day when someone comes up with another good open-sourced alternative and I would happily 'jump ship' over.


3. Regarding speed

It doesn't take a genious or encoding tests to determine which transcoding method is faster, you just have to look at the processes involved in each method.

BeSweet Pre-gain
1. Decode AC3, find the gain
2. Decode AC3, applying gain and encoding to MP3 on the same pass

BeSweet Post-gain
1. Decode AC3, encode to MP3 on the same pass, finding the gain
2. Apply globalgain

HeadAc3he
1. Decode AC3, find the gain
2. Encode to MP3 applying the gain at the same time

All 3 processes involve a decode AC3 and encode MP3 pass, so let's look at what the extra pass do:

BeSweet Pre-gain: Decode an AC3
BeSweet Post-gain: Apply globalgain
HeadAc3he: Write a big wav file

Obviously Post-gain would be the fastest, followed by HeadAc3he, and Pre-gain will be the slowest.


4. Regarding postgain/mp3gain/globalgain

Using mp3gain to normalize CD-audio rips is inanimously the method chosen by the music-audio encoding community, at least by the people who know they have the choice. We believe mostly in keeping the original untouched as much as possible before encoding. Should the movie-audio encoding community follow suit? When I first proposed the use of globalgain to this community, there were a lot of resistance to the idea (imagine, DA and DG ganging up together against me! They agreed on something! :eek: ), but slowly some people started drifting over.

Should the movie-audio community follow the music-audio community in this respect? There may be reason not to, and this is because music CDs in general do not need as much gain than DVD audio which generally tend to be of much lower volume, so there is a difference in the situations. In most cases, I see CD encodings requiring gains of -4.5 to +7.5 while for movie audio, +6 to +18 is usually required.

The main argument brought up against the use of globalgain is the effect on the ATH curve, whereby if you do not normalize the original audio prior to encoding, you will lose a lot of things dropping below the ATH curve. There are a few problems to this argument.

a. It is known that lame does ath auto-adjusting depending on the level of the input stream. It does not work perfectly, but it works well. I discussed with Robert (from LAME) on this issue before.

b. Also in a discussion with Robert, he mentioned that a 6dB difference is not very significant on the ATH

c. In the first place, the ATH curve makes assumptions on the playback level. It is definitely not perfectly accurate, and really cannot be, and is at best an estimation and guestimation. For example, let's say at one playback level, tone A may mask tone B. Raise the volume and B may get unmasked, raise it further and B might become masked again.

d. Tones which are likely to be affected are those which are barely audible anyway. Dropping them will mean better quality to the more audible tones. It's a tradeoff which might not necessarily be bad.

e. Using pre-gain, you will likely end up with another problem, increase of noise. Noise which were previously below the ATH could be pushed above the ATH from the pre-gain and not only affect the decoding with noise but eat up bits which reduce the quality of the audible tones.

The other argument is based on quantisation error, whereas at lower volume levels quantisation is not accurate. This argument isn't quite valid because MP3 uses a non-linear quantiser to quantise the coefficients of transform based on a scale of power of 4/3, in another words lower coefficient levels are quantised with higher precision.

All in all, there should really not be a problem as long as it is not an extreme case such as 110dB, which I personally think is unheard of, and very unlikely to happen. I've really only seen up to 24dB, but I haven't been encoding as much as most of the people posting regularly in the forum.

In conclusion, I believe that the benefits of postgain and more than worthwhile. Quality wise, it would not be the same as pregain, and one cannot absolutely say if it would be worse, better or similar. I can say that for most people out there the difference is inaudible, and in my opinion the quality should be better. This, plus the fact that postgain method is faster is enough for me to choose the postgain method.

One last final advantage of post-gain is that you can guarantee that with post-gain applied, you can absolutely guarantee that the decoded playback will not clip and will have the highest volume possible (within 1.5dB). With pre-gain, there is no such guarantee, and you cannot be sure if the decode playback will clip or have the highest volume possible.


5. Regarding floating point

Personally, I think floating point is overrated. 32bit fixed point provides better 'dynamic range'. Consider that all 2^32 in 32bit fixed point is used, and very little of the 2^32 possible values in 32bit floating point is actually used. But really, it is even questionable if one can tell the difference between 15bit and 16bit fixed point...


6. Regarding SSE compiles

AFAIK Lame has not been optimized for SSE vectors and test compiles by Dibrom and a few others have shown that SSE compiles perform slower than MMX, so I would be wary of SSE compiles.


7. Regarding --scale

I'm just copy and pasting what I've said months ago, but just to emphasise it again:

Personally, I think you should by default override the --alt-preset's --scale. If a user uses pre-encode normalisation, then it would be silly to do another --scale in LAME. If a user uses post-gain, then --scale is useless. Either way, --scale should not be used.

This affects the ABR/CBR alt-presets and --r3mix which have defaulted --scale values below 1.



Hopefully I've helped clear up a few things. If anyone have any queries, I'll be happy to answer. I'll watch this tread for a few days.

[DSPguru]

thank you tangent, for sharing with us your point of view.
Originally posted by tangent
In conclusion, I believe that the benefits of postgain and more than worthwhile. Quality wise, it would not be the same as pregain, and one cannot absolutely say if it would be worse, better or similar. I can say that for most people out there the difference is inaudible, and in my opinion the quality should be better. This, plus the fact that postgain method is faster is enough for me to choose the postgain method.

One last final advantage of post-gain is that you can guarantee that with post-gain applied, you can absolutely guarantee that the decoded playback will not clip and will have the highest volume possible (within 1.5dB). With pre-gain, there is no such guarantee, and you cannot be sure if the decode playback will clip or have the highest volume possible.needless to say more :D.

5. Regarding floating point

Personally, I think floating point is overrated. 32bit fixed point provides better 'dynamic range'. Consider that all 2^32 in 32bit fixed point is used, and very little of the 2^32 possible values in 32bit floating point is actually used. But really, it is even questionable if one can tell the difference between 15bit and 16bit fixed point...yea, we discussed it before, and i agreed that 32bit fixed-point would be better than 32bit floating-point, but still, 32bit floating-point is better than 16bit fixed point :p.


as for scale,
although lame_enc.dll uses scale 0.93, almost every user who uses BeSweet will be using scale 1, 'cause it's in the BeSweetGUI profiles, it's defaulted by GKnot and appears in the Doom9's guide.

as for ogg vorbis post-gain,
since ogg vorbis developers didn't define a global_gain tag for their file structure, i had to define a gain tag of my own. in fact, for a while now, you can use BeSweet also to encode and assert postgain.
currently, my ogg vorbis postgain tag is only supported by winamp.
hopefully, it will be supported in the next version of tobias' oggds.
you're invited to check it out :).

again, thank you,
Dg.

[tangent]

Originally posted by DSPguru
as for ogg vorbis post-gain,
since ogg vorbis developers didn't define a global_gain tag for their file structure, i had to define a gain tag of my own. in fact, for a while now, you can use BeSweet also to encode and assert postgain.
currently, my ogg vorbis postgain tag is only supported by winamp.
hopefully, it will be supported in the next version of tobias' oggds.
you're invited to check it out :).[/B]

Oh ok. I suppose you're using the RG_PEAK tag?

[DSPguru]

Originally posted by tangent


Oh ok. I suppose you're using the RG_PEAK tag? i considered using it, but at the end i decided to create another tag.
it's called "LWING_GAIN".

[tangent]

Originally posted by DSPguru
i considered using it, but at the end i decided to create another tag.
it's called "LWING_GAIN".
Erm... although the RG tags have not yet officially been adopted by the Vorbis developers, it's the cloest thing we have to a standard tag, I'm afraid that creating yet another tag would just create even more confusion amongst decoder developers, so I don't think that's a good idea.

Any particular reason you chose to go with your own tag rather than with RG_PEAK?

[DSPguru]

Originally posted by tangent

Erm... although the RG tags have not yet officially been adopted by the Vorbis developers, it's the cloest thing we have to a standard tag, I'm afraid that creating yet another tag would just create even more confusion amongst decoder developers, so I don't think that's a good idea.you're right, but i'm afraid that lately there were talkings about renaming RG_PEAK with REPLAYGAIN_PEAK, etc'..

Any particular reason you chose to go with your own tag rather than with RG_PEAK? at first, i used RG_PEAK, but then i noticed that almost every1 got confused between the (post)normalization concept to the replaygain concept.
there were too many questions, and too much mess.
so i thought it would be better, to have a clear seperation between the two.

[everwicked]

Originally posted by Doom9
@dark avenger & everwicked: I invite you or anyone else to find me an AC3 taken from any DVD movie where you can here the effects that both DSPGuru and DarkAvenger have explained.

Sorry, I got better things to do.

Originally posted by DSPguru
do you really want me to show everybody what happens to headac3he when i use +100db gain ?
or maybe you think that it's simply nonrelevant.

the main reason that darkavenger & everwicked doesn't suggest using --scale 1 and PostGain is simply because headac3he doesn't offer it.


Sure, post away.

I hope you don't really think that --scale 1 actally does something. PostGain is another story.

Originally posted by canman
Agenda, nope, unhappy yes sometimes, happy most of the time.

It was very nice of you to come by our little cozy IRC channel, you should have stayed longer. Your /whowas information was interesting though, too bad you forgot to change your "name" properly before switching servers.

<everwicked> at openprojects:
<everwicked> canman was ~na@cpe.atm2-0-105267.0x3ef2f282.arcnxx11.customer.tele.dk * dvd2svcd
<everwicked> at efnet:
<everwicked> dvd2svcd was ~test@cpe.atm2-0-105267.0x3ef2f282.arcnxx11.customer.tele.dk * No Comments

Well, that figures. A simple check at the forum access IPs will show more. Wonder what's going on in this forum lately.

I rest my case.

[tangent]

Originally posted by everwicked
I hope you don't really think that --scale 1 actally does something.

"--scale 1" is used to override Dibrom's --scale setting in the --alt-preset. Dibrom's --scale setting should not be used with DVD audio especially if you plan on normalising with either pre-gain or post-gain. I explained it more in detail in this old thread: http://forum.doom9.org/showthread.php?s=&threadid=13317&highlight=mp3gain

EDIT: Fixed ambiguity in confusing sentence structure. Thanks to doom9 for pointing it out.