alt presets are in official lame dll!

[DarkAvenger]

All lame_enc.dll with 1.27 interface will have the alt presets inside, as john33's (unfortunately old) code was up'ed to CVS. This code still has the bug that mono files don't work properly, so you need the dll on my site or on Roberto's, but I guess in near future the fix will be official, as well. :)

[Gabriel_Bouvigne]

Important:

Who (as a programmer) is using presets from the dll?

[DarkAvenger]

I guess everyone who seriously uses the dll.

[Gabriel_Bouvigne]

I mean that considering the fact that this feature was introduced recently in the alpha dll, there are probably not so many people using it in their program.

I'm asking because I'd like to change the enum values in order to be on par with the enum used inside libmp3lame.

[DSPguru]

@gabriel
there are two known versions of lame_enc.dll that offers alt-preset.
there's the release by john33, who "hacked" lame_enc, so that alt-preset can be used in cdex. and, afaik, this hack made it into cdex cvs recently. (he replaced some of the presets into alt-presets).

there's a release of "hacked" lame_enc.dll by me (used by BeSweet).
(i've implemented the alt-presets in addition to the current presets list)
source-code can be found on my webpage.

[Gabriel_Bouvigne]

So you think that there could be only BeSweet and CdEx which are using it yet?

I'm wondering because I'd like to change the enum values and I'd like to know who I should contact.
The change is basically to have values from 8 to 320 for abr presets.
Now that I started including alt-presets into libmp3 lame, it will allow the dll and the command-line to be always in synch, without any need to duplicate code for presets (like it's the case now)

[DarkAvenger]

john33 made several releases. First ones were replacement, but the newest (well not so new anymore) one, which are now in Lame CVS, are additions.

@Gabriel

Well, I don't quite get what you mean with the enum vaue, but it is good that you try to synch the dll and exe. Keep it up! :)
BTW, HeadAC3he uses the (now) official one (well with a fix for mono files, I can send oyu john33's code, if you like), like CDEX.

[DSPguru]

Originally posted by Gabriel_Bouvigne
I'm wondering because I'd like to change the enum values and I'd like to know who I should contact.
The change is basically to have values from 8 to 320 for abr presets.i suggest that you go over my sources.
i believe my solution is good, because :
a. it works (all alt-presets : abr,vbr,cbr)
b. it's backward compatible to current enum list

as for the actual tuning, i agree it should be implemented in the lib itself, and should only be called thru the parser (frontend) or the enum list (dll).

[Gabriel_Bouvigne]

Standard extreme and insane are now inside libmp3lame, so the code is not anymore into the dll or the executable.

But for the abr ones, the point is that I'd like to have, as an example, an enum value of 120 for abr 120kbps. However some values in the range of 8-320 are already used in the dll

[DarkAvenger]

I don't have any problem with john33's solution, but I haven't tested intensively. Whatever you decide, please apply the fix for mono flies. Most of the prestes are dierectly setting the stereo mode, without actually checking whether the nMode value is set to BE_MP3_MODE_MONO.
Is there a way to disable Lame's automatic resampling in ABR (or just Alt ABR)? I know it may make sense, but I think it is better if you can choose what you want.

[Gabriel_Bouvigne]

About the mono/stereo thing: It's not really a preset problem, but more a libmp3lame problem. But you're right, this should be fixed.
A temporary solution would be for you to set mono AFTER setting the preset.

For the sampling rate, the solution is to set resample to the input value. (this won't resample)
It's an extra step you have to do, but I think that the default should be to resample if needed.
On your side, you could hide it in a check box like "do not resample", and if checked then set resample to the input freq value.

[DarkAvenger]

About resampling: That does not work, in ABR (at least alt abr, perhpas john33's mistake, dunno) lame resamples anyway.

[Gabriel_Bouvigne]

So it's a problem with the dll because from the command line it works

...ok, I see the problem now (btw the dll is even more messy than the command line)
The problem with the dll is that you can't control the order in which parameters are applyed. And unfortunately the resampling as applyed before the presets, so presets are overriding it.

[DSPguru]

in my solution i export gfp, so i can change params After presets were applied. (--scale for instance).

btw,
if my solution won't become official, i'll just keep creating my "hacked" versions of lame_enc.dll :).

[Gabriel_Bouvigne]

Exporting gfp seems to be an interesting solution, but it would also allow every bad thing.

Perhaps as a "not recommended" api?

[DarkAvenger]

I would like to have access to the more internal settings, as well!

[DSPguru]

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? it allows every bad thing, but it will only be used by advanced developers anyway.

[john33]

Hi, DarkAvenger suggested that perhaps I should join this debate.

@Gabriel, surely the person most likely to know who is making use of the dll beyond CDex and the guys here would be Albert Faber? Assuming there is no other usage, I would think that since BladeMP3EncDLL.c uses the names, and presumably the same is true here, re-assigning enum values in BaldeMP3EncDLL.h should not cause a problem. Incidentally, your latest changes in lame.h assign an enum value of 1000 to R3MIX and in BladeMPEncDLL.h that same value is assigned to LQP_PHONE. Considering how the alt preset ABR is currently coded, it's not clear to me how you would use the enum values you propose assigning. On a slightly different matter, there is one thing you could do that would bring the dll in line with the ABR and CBR presets in parse.c and that is to replace the abr_switch_map in the dll code with the one out of parse.c. Separating the presets from the main code is clearly a sensible thing to do and there is no reason why the alt presets ABR and CBR code couldn't also go in to the presets.c as well. I have a later version of the dll where I have taken all the presets, including ABR and CBR, out of the dll code and put them in a file I also called presets.c!

Anyway, just my 2cents worth. I have no axe to grind whatever happens. My only interest is in trying to help give people what they want.

john33

[DSPguru]

Originally posted by john33
Separating the presets from the main code is clearly a sensible thing to do and there is no reason why the alt presets ABR and CBR code couldn't also go in to the presets.c as well. I have a later version of the dll where I have taken all the presets, including ABR and CBR, out of the dll code and put them in a file I also called presets.c!i agree.
alt-presets should be implemented inside presets.c, and not in parse.c.
that way, both frontend&dll versions would only need to call the relevant function over presets.c, and therefore supply the same result.


as for enum issues,
i suggest that you check my solution. it's simple and working.


EDIT : in case you don't know what's my solution (http://www.geocrawler.com/archives/3/7323/2002/3/0/8115336/), here it is :
Originally posted by DSPguru
here are the new enumarations :
{
ALTP_CBR =20000,
ALTP_STANDARD =21000,
ALTP_FAST_STANDARD =21100,
ALTP_EXTREME =22000,
ALTP_FAST_EXTREME =22100,
ALTP_INSANE =23000,
ALTP_ABR =24000,
}

so we have :
alt-preset fast standard = ALTP_STANDARD+100
alt-preset fast extreme = ALTP_EXTREME+100
alt-preset 128 = ALTP_ABR+128
alt-preset cbr 196 = ALTP_CBR+196

nuf said, i believe my point is clear.. :)
for more info, download the sources.

Dg.

[Gabriel_Bouvigne]

Ok, here is what I plan:

alt-preset 128 -> enum value of 128
alt-preset 162 -> enum value of 162

For standard, extreme, insane, I can change the enum values in parse.c to the one used in the dll if you want.

I also think that there is no real need for enum values controling alt-preset in cbr mode. The code and tuning are the same as for abr, only the vbr mode is set to off. (I plan to do this way soon for alt-preset cbr in the exe)

PS: yes, I plan to also put alt-preset abr code inside libmp3lame. I just didn't had enough time yet.

[DSPguru]

@gabriel
please add the GetGFP function for my code to the official lame_enc.dll