Headac3he audio encoding replacement for GKnot

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