--alt-preset's in Besweet 1.3RC

[AndyP]

Hi, can I just check something.

According to http://www.ff123.net/cbr128.html the following is true:

--alt-preset 128

is synonymous with

--abr 128 -h --nspsytune --athtype 2 --lowpass 17.5 --ns-bass -6 --scale 0.93

(and I assume if I add/alter --scale 1 to both they are still the same)

If I use Besweet 1.3RC with the lame setting --alt-preset 128 --scale 1 I get a file that is 24MB larger than if I use the latter setting (with --scale 1). Why is this the case?? Surely they should be the same file.

Logs -

1st - Using --alt-preset 128 --scale 1

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 : 05/23/02 , 10:15:27.

BeSweet -core( -input e:\dvd\saving_private_ryan\saving private ryan 5.1 delay 0ms.ac3 -output e:\dvd\saving_private_ryan\Saving Private Ryan alt 128kbps.mp3 -logfile BeSweet.log ) -azid( -C normal -L -3db ) -ota( -d 0 ) -lame( --alt-preset 128 --scale 1 )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : e:\dvd\saving_private_ryan\saving private ryan 5.1 delay 0ms.ac3
[00:00:00:000] | Output: e:\dvd\saving_private_ryan\Saving Private Ryan alt 128kbps.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: None
[00:00:00:000] | LFE levels: To LR -3.0dB, To LFE 0.0dB
[00:00:00:000] | Center mix level: 136.8db
[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] | 'abr 128' preset is used
[00:00:00:000] +---------------------
[02:42:23:040] Conversion Completed !
[02:42:23:040] Actual Avg. Bitrate : 116kbps
[00:43:10:000] <-- Transcoding Duration
Logging ends : 05/23/02 , 10:58:37.

File size - 138530KB

2nd using --abr etc..

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 : 05/23/02 , 13:02:53.

BeSweet -core( -input e:\dvd\saving_private_ryan\Saving Private Ryan 5.1 delay 0ms.ac3 -output e:\dvd\saving_private_ryan\Saving Private Ryan alt128 128kbps.mp3 -logfile BeSweet.log ) -azid( -C normal -L -3db ) -ota( -d 0 ) -lame( --abr 128 -h --nspsytune --athtype 2 --lowpass 17.5 --ns-bass -6 --scale 1 )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : e:\dvd\saving_private_ryan\Saving Private Ryan 5.1 delay 0ms.ac3
[00:00:00:000] | Output: e:\dvd\saving_private_ryan\Saving Private Ryan alt128 128kbps.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: None
[00:00:00:000] | LFE levels: To LR -3.0dB, To LFE 0.0dB
[00:00:00:000] | Center mix level: 136.8db
[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:42:23:040] Conversion Completed !
[02:42:23:040] Actual Avg. Bitrate : 96kbps
[00:34:35:000] <-- Transcoding Duration
Logging ends : 05/23/02 , 13:37:28.

File size 114596KB

Andy

[DSPguru]

hmm, i guess the dll somehow ignores some of the switches.
i'll check this out.

btw, if you want to test the --alt-preset functionality, i would suggest that you take a wave file and encode it with BeSweet v1.3RC & lame 3.92 with --alt-preset 128, then compare the results.

[AndyP]

Thanks for your prompt reply!!

I can confirm the following

I ran the same WAV file (8627KB Angel.wav) through the following

Besweet 1.3RC (with standard 3.92 lame_enc.dll)
LAME 3.92

For each I did the --alt-preset 128 and the --abr 128 etc...
(no --scale 1 this time, used --scale 0.93 for --abr 128 as defined)

Results:
LAME 3.92 --alt-preset and --abr - identical (binary compare) size 772KB

Besweet 1.3RC --alt was about same size as LAME 3.92 but not identical
--abr was much smaller (721KB v. 772KB)

Logs (--alt-preset then --abr)
LAME commandlines - you'll just have to trust me :)

If I can give you any more info don't hesitate to ask
I don't know if its relevant (i was reading the thread about lame_enc speed) and I note that the --alt-preset is slower.

Cheers, Andy

BeSweet v1.3RC by DSPguru.
--------------------------
Using lame_enc.dll v1.28 (18/4/2002), Engine 3.92 <http://www.mp3dev.org/>.

Logging start : 05/23/02 , 20:07:42.

BeSweet -core( -input e:\temp\angel.wav -output e:\temp\angel.mp3 -logfile BeSweet.log ) -lame( --alt-preset 128 )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : e:\temp\angel.wav
[00:00:00:000] | Output: e:\temp\angel.mp3
[00:00:00:000] | Floating-Point Process: Yes
[00:00:00:000] | Source Sample-Rate: 44.1KHz
[00:00:00:000] +-------- LAME -------
[00:00:00:000] | 'abr 128' preset is used
[00:00:00:000] +---------------------
[00:00:50:076] Conversion Completed !
[00:00:50:076] Actual Avg. Bitrate : 126kbps
[00:00:13:000] <-- Transcoding Duration
Logging ends : 05/23/02 , 20:07:55.

BeSweet v1.3RC by DSPguru.
--------------------------
Using lame_enc.dll v1.28 (18/4/2002), Engine 3.92 <http://www.mp3dev.org/>.

Logging start : 05/23/02 , 20:10:44.

BeSweet -core( -input e:\temp\angel.wav -output e:\temp\angel abr128.mp3 -logfile BeSweet.log ) -lame( --abr 128 -h --nspsytune --athtype 2 --lowpass 17.5 --ns-bass -6 --scale 0.93 )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : e:\temp\angel.wav
[00:00:00:000] | Output: e:\temp\angel abr128.mp3
[00:00:00:000] | Floating-Point Process: Yes
[00:00:00:000] | Source Sample-Rate: 44.1KHz
[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] +---------------------
[00:00:50:076] Conversion Completed !
[00:00:50:076] Actual Avg. Bitrate : 117kbps
[00:00:07:000] <-- Transcoding Duration
Logging ends : 05/23/02 , 20:10:51.

[DSPguru]

if you've read that relevant thread and have some experience with my work, you should know by now that i had my own implementation of lame_enc.dll v3.91 that used to create IDENTICAL prodcuts to lame.exe v3.91.
since v3.92, it's another implementation and not mine.

i'll consider modifying v3.92...
although i really think that the official release is good enough.

[AndyP]

Hi, I hope you don't think I was being critical. I couldn't care less if your --alt-preset and LAME 3.92 --alt-preset don't match exactly. Yours is far faster and the quality better than an azid then lame seperatly. I was merely doing what you suggested and sharing it.

No offence intended

Andy

[DSPguru]

all cool.. :).

thank you for sharing your test results. appreciated!

[DSPguru]

@AndyP
issue should be fixed in BeSweet v1.3RC2.
check it out :D.

[Gabriel_Bouvigne]

Just a note to say that --alt-preset xxx can NOT be exactly matched by other command line switches. It uses some things that are only turned on when using --alt-preset xxx.

[AndyP]

Hi

Thanks for the new version.

Gabriel, You can make an exact (binary compare identical) copy using the following (from which --alt-preset 128 was derived)

--abr 128 -h --nspsytune --athtype 2 --lowpass 17.5 --ns-bass -6
--scale 0.93

DSPguru, you are a scholar and gentleman!! :)

Andy

[Gabriel_Bouvigne]

Yes, just checked the code and you are right.
Abr presets can be reproduced using command line switches. Only full vbr presets can not.

[DSPguru]

Originally posted by Gabriel_Bouvigne
Just a note to say that --alt-preset xxx can NOT be exactly matched by other command line switches. It uses some things that are only turned on when using --alt-preset xxx. i did a binary compare with hexeditor. the only difference is in the start of the file (the xing vbr tag).Originally posted by Gabriel_Bouvigne
Yes, just checked the code and you are right.
Abr presets can be reproduced using command line switches. Only full vbr presets can not. what about that idea of adopting my patch into cvs ?

ps,
10q Andy :).

[Gabriel_Bouvigne]

Could you remind me the purpose of your patch?

[DSPguru]

Originally posted by Gabriel_Bouvigne
Could you remind me the purpose of your patch? sure !
the purpose is exporting gfp :D.

[Gabriel_Bouvigne]

Ok, In this case: sure, no

Let me explain: gfp is an internal structure. Some parameters, when changed, might need to change some other parameters. Some might have invalid values in order not to crash,....

This is really an internal structure, and should not be modified outside. What you should use are the set/get functions exposed into lame.h

That's what the command-line frontend and the dll are using. Unfortunately it seems that the dll interface is mainly an extra layer over those set/get which as some restrictions.

I perfectly understand that you need to access more parameters. The way you should do this is not by changing gfp directly, but by using set/get.

A good solution would be to expose those set/get through the dll interface. It seems to me that tis would be a good solution.

Your current solution involve too much risk. It assumes that you perfectly know the parameters that you're changing. As the dll is widely used, this can not be assumed for everyone, and would lead to too many questions and problems.

So I'm sorry but your current way can't be incorporated. However you might consider exposing set/get into the dll interface. This would probably be included into the main distribution.

[DSPguru]

Originally posted by Gabriel_Bouvigne
Your current solution involve too much risk. It assumes that you perfectly know the parameters that you're changing. As the dll is widely used, this can not be assumed for everyone, and would lead to too many questions and problems.i agree this is not intented to be used by everyday user, but on the other hand this could be a 'develpoers-only' feature (even an undocumanted, if you like).

if you'll check my implementation you'll see that i didn't add a new function to lame_enc.dll and that the dll has the same functions exported as the official release. everything is 100% backward compatible.
only developrs could find this tweak in the sources.
therefore, i frankly can't see how many questions and errors can be raised by that.

please reconsider. but if you decide not to, i hope you understand me when keeping producing my own builds.


ps : we already discussed this in the past.
your answer then was (http://forum.doom9.org/showthread.php?s=&postid=115979#post115979) :Originally posted by Gabriel_Bouvigne
Exporting gfp seems to be an interesting solution, but it would also allow every bad thing.

Perhaps as a "not recommended" api?

[Gabriel_Bouvigne]

The problem with "experimental" or "developper only" options/api is that they always become used by a lot of people, and after it's impossible to get rid of them.

I have absolutely no problem with the fact that you keep your modified build. You are free to do it, and it seems to me a good way to experiment new api features if some are missing.

Do you think that there would be something that you can do now and you couldn't do with set/get exposed?

[DSPguru]

true, set/get is basicly all i need, but since i don't want to have a static linkage to lame_enc.dll (in order to support future versions of it), i would have to GetProcAddress of a looong list of set/get functions.
that's too much work, and i honestly believe i know what i'm doing when modifying gfp directly.

[Gabriel_Bouvigne]

GetProcAdress??? Are you using loadlibrary?

Why not using dynamic linking instead of manual linking/loading?
There is probably a reason, but I'd like to know it in order to better understand your problem.

[DSPguru]

Originally posted by Gabriel_Bouvigne
GetProcAdress??? Are you using loadlibrary?yes.

Why not using dynamic linking instead of manual linking/loading?
There is probably a reason, but I'd like to know it in order to better understand your problem. are you talking about using a .lib file that would do the work for me ? well, i predict having problems with future versions of lame_enc.dll.

[Gabriel_Bouvigne]

Yes, a .lib.

Should I understand from your post that using a .lib makes you using fixed address, and that if the addresses change you'll be screwed?

Yes, if a .lib makes you using fixed addresses, it's a problem. In this case would there be a way to force export adress when compiling lame_enc.dll?

[DSPguru]

Originally posted by Gabriel_Bouvigne
Yes, if a .lib makes you using fixed addresses, it's a problem. In this case would there be a way to force export adress when compiling lame_enc.dll? you can force address export when compiling with msvc (using def), but in my experience it changes when compiling with icl.

anyway, i recalled what made me stop using .lib files.
BeSweet supports a long list of dlls (lame_enc,mp2enc,ssrc,azid,mpglib,ogg,vorbis,vorbisenc), but only using a partial list of them at once. i don't want to load unneeded libraries.
in fact, if a BeSweet user only use it in order to encode MP2 for svcds, he doesn't need all those dlls, and don't want BeSweet to quit for not being able to found lame_enc.dll.