Hello, would it be possible to make a "front-end" dll to control existing Lame dll,
Here's what the front end DLL would do:
1) it would accept a normal Lame command line
2) it would add a command line from external txt file and keep only the file related settings (infile/outfile) from the input command line
3) it would pass this modified cmd line to existing Lame dll.
Reason for this is that I want to use Oddcast (now Edcast) for sending mp3 stream, and it does not allow any settings on the mp3 encoder, and probably passes some exotic switches which I'm not aware of, messing up the quality.
How about "lame_enc.dll modified to use INI file setup" ?
How about "lame_enc.dll modified to use INI file setup" ?
I just looked up that, it's close but not exactly what I need. I'd like to be able to set up more parameters than just "Preset, Stereo, Scalefactor and Experimental Y options to be used in encoding". And I'd like to use another Lame version which I found works better for low bitrate CBR encoding with my music.
But thanks anyway, if I can't get what I'm crying for , I'll use the modified DLL.
What LAME version and setting would that be?
What LAME version and setting would that be?
With the answers to these questions, it becomes a definite 'maybe'!! Adding to the number of options exposed within the ini file is relatively straightforward and, if you particularly want it compiled against a specific lame library, that should be simple enough depending on the library.
I'm almost afraid to post any custom commandlines here
But this is a setting which works well on most of my trance tracks:
Lame 3.89
-b96 -q1 --nspsytune --resample 44 --lowpass 16 --ns-bass -4 -X1
Also works good:
Lame 3.93.1
--alt-preset cbr 96 -q1 --lowpass 16 --resample 44 --ns-bass -2 -X1
Of course these are experimental switches so that's why I wanted to have external txt file with the command line if I wanted to make changes. But even if someone could make a Lame DLL with the fixed command line, I would be thankful for this too
(I remember asking john33 a long time ago for such modded dll, but 1) the command line was different 2) the Oddcast DSP still managed to "push through" some switches which audibly altered the quality in some cases).
Thanks for any help
Well, the options shouldn't be a problem. The only available 3.89 code is beta, but I have that and 3.93.1. I'll go back to the dll code that came with those and look at modifying it. Leave it with me for a couple of days and I'll get back to you.
Well, the options shouldn't be a problem. The only available 3.89 code is beta, but I have that and 3.93.1. I'll go back to the dll code that came with those and look at modifying it. Leave it with me for a couple of days and I'll get back to you.
Thank you very much John, you are always to help! Yes you are right it is beta.
The only thing I'm afraid of is that these setting are slooow (2x realtime at most) and that the audio might "stutter". I guess we'll see, and if there are any problems with that well I'm just building a new powerful PC, that should take care
P.S. I don't need both, I slightly prefer the sound of 3.89 so that's all I need.
Did you do an ABX compare to the most recent lame version? Perhaps you will be surprised how good the presets sound.
Another Oddcast user here. I also would like to see a lame_enc.dll with all the options exposed in a text file.
Another Oddcast user here. I also would like to see a lame_enc.dll with all the options exposed in a text file.
All seems a bit excessive! But if you could provide a list of those you would like to have available, I'll see what I can do.
If anyone else has any requests regarding this, let's have them all together for the sake of minimising effort.
Did you do an ABX compare to the most recent lame version? Perhaps you will be surprised how good the presets sound.
I did not do an ABX test but I did extensive testing and comparing on my killer samples and real trance songs. At 96kbs you really do not need to do an ABX test as the artifacts are ultimately obvious at this bitrate, and I already know which LAME version makes which artifacts @96kbs
@john33, It's perfectly fine for me if you do only the 3.89 cmd line as I put above, just please disable any switches from the input cmd line except infile/outfile, thanks
All seems a bit excessive! But if you could provide a list of those you would like to have available, I'll see what I can do.
Thank you. There are actually not that many quality-related options, most deal with I/O and tagging. Are you be doing entire command lines or individual presets?
I'd like to see -V (already done in the latest version), -b, -B, --lowpass, -q
OK, guys, thanks for your input. I'll see what I can do.
OK, here is a 3.98 version that I think covers everything asked for: http://rarewares.org/files/mp3/lamedll_MOD3.98.zip (http://rarewares.org/files/mp3/lamedll_MOD3.98.zip)
If this is OK, I'll look at a 3.93.1 version, but I'd like to know whether this works as required, first. (Check the new ini file as the options have expanded, obviously!)
Thank you for this release. It works well.
My plan is to stream real radio over LAN (hence --lowpass) and I just discovered that -V2 is not transparent.
Thank you for this release. It works well.
My plan is to stream real radio over LAN (hence --lowpass) and I just discovered that -V2 is not transparent.
OK, thanks. I'll look at moving this to 3.93.1 in the next couple of days.
I want to use Oddcast (now Edcast) for sending mp3 stream, and it does not allow any settings on the mp3 encoder, and probably passes some exotic switches which I'm not aware of, messing up the quality.
I just checked the output of official LAME 3.97 DLL / latest Edcast, and it
did not use the bit reservoir at all. A 96 kBit stream came out full of \0 and the lame id string, when these bytes could be spent for quality instead. I wonder what could be the reasoning behind this choice. Yes, the first couple frames will play distorted, but it's not like the listeners restart playback every minute.
A quick browse over the Icecast directory revealed two (http://stream001.radio.hu:8080/mr3.mp3) servers (http://mp3.live.tv-radio.com/franceinter/all/franceinterhautdebit.mp3) still publicly 'casting in this format.
john33, what is the format of the resample option? It does not do anything. Edcast's built in resampler (BASS?) is unusable – produces clicks.
john33, what is the format of the resample option? It does not do anything.
BUMP.
I'll correct myself. The parameter works, but the host application is able to override it. This shouldn't be happening.
john33, what is the format of the resample option? It does not do anything.
BUMP.
I'll correct myself. The parameter works, but the host application is able to override it. This shouldn't be happening.
Sorry about that! I've corrected that and there's a new compile here: http://rarewares.org/files/mp3/lamedll_MOD3.98.zip (http://rarewares.org/files/mp3/lamedll_MOD3.98.zip)
The problem is now corrected. Thank you.
Just curious - there are apparently two versions available: lame_dll_MOD3.98.zip (dated 11-Aug-2008) and lamedll_MOD3.98.zip (dated 19-Aug-2008). The 2nd one seems to accept more options. From Rarewares, only the 1st one is linked. I'm wondering which one to use
Just curious - there are apparently two versions available: lame_dll_MOD3.98.zip (dated 11-Aug-2008) and lamedll_MOD3.98.zip (dated 19-Aug-2008). The 2nd one seems to accept more options. From Rarewares, only the 1st one is linked. I'm wondering which one to use
Use the more recent one. It will be replacing the earlier one. I was just waiting to be sure there weren't any issues that needed attention.
I'd like to see -V (already done in the latest version), -b, -B, --lowpass, -q
IIRC all those options were included in the ordinary (not the ini file setup modified)
lame_enc.dll before except for
--lowpass, am I wrong?
john33, can you suggest the best TAGing option for making MP3 through lame_enc.dll ? Including such a command line in the dll doesn't make any sense:
--id3v1-only --ta "%a" --tt "%t" --tg "%m" --tl "%g" --ty "%y" --tn "%n" %s %d
...I don't have a clue...
I'd like to see -V (already done in the latest version), -b, -B, --lowpass, -q
IIRC all those options were included in the ordinary (not the ini file setup modified) lame_enc.dll before except for --lowpass, am I wrong?
They were all available to an application using the dll, but the point of the ini file version is that the options are configured within the ini file rather than by the application that uses it. In fact, the application set options are ignored.
john33, can you suggest the best TAGing option for making MP3 through lame_enc.dll ? Including such a command line in the dll doesn't make any sense: --id3v1-only --ta "%a" --tt "%t" --tg "%m" --tl "%g" --ty "%y" --tn "%n" %s %d
...I don't have a clue...
The file i/o and any tagging are the responsibility of the calling application and, as such, are governed by what the calling application offers. The only 'tag' that is under the control of the dll in terms of whether it is written is the lame-tag.
@jmartis Sorry for the delay, but here is a new modified 3.93.1 dll: http://rarewares.org/files/mp3/lamedll_MOD3.93.1.zip (http://rarewares.org/files/mp3/lamedll_MOD3.93.1.zip) It is slightly different to the 3.98 version, so you'll need to check the ini file for usage. Let me know if it's OK, or otherwise.
I've now uploaded the expanded 3.98 version as the 'official' modified version on Rarewares.
Hello John, I configured lame_enc.ini like this: (Edit: this is for 3.98 MOD)
LamePreset=CBR96
b=0
B=0
q=3
Stereo=JS
Scale=0.0
Resample=44100
Lowpass=15000
ExperimentalY=0
ExperimentalX=10,3
As you can see the stream should be CBR 96kbs 44100Hz. In the oddcast plugin, there is set 40kbs and 16khz which should be ignored by the lame dll.
However, the resulting stream is around 110kbs, it is VBR and with 16khz sample rate which oddcast managed to push through.
1) Why the CBR preset does not work?
2) How could oddcast push through the sample rate parameter?
EDIT: Thanks John, I'll try it out. Just sorting out the 3.98 one now.
EDIT2: did you include the custom parameters line in the 3.93.1 mod?
Just tried the 3.93.1 now, and it also produces VBR output no matter what.
Can't confirm this. 96 kBit/s stream is being produced at the requested sampling rate. Sampling rate in Oddcast does influence the AF bandwidth, but LAME nevertheless produces output rate configured in the ini.
Never leave the sampling rate parameter in standalone Oddcast to anything else than 44100. The program is always recording at this rate and will pointlessly resample, the resampler is also poor quality. Resample with lame if needed and supply the input with true 44100.
The Foobar plugin will operate at whatever rate is incoming from foobar. Use PPHS resampler if needed and set Oddcast's rate to match it.
hmm, I use Winamp plugin, and its not Oddcast but Edcast now. The sample rate in Edcast ovverrides "resample" parameter in Lame dll.
The stream is produced VBR, even though I have set "CBR96" in the .ini file.
I don't pay respect to anybody's trademarks.
The issue with sampling rate was already fixed in 3.98, wasn't it? I reported it to John33 and he uploaded a new version.
I downloaded the version from Rarewares and it does not work. I tried "CBR96" and "CBR096", but always the stream produced is VBR and seems to be average bitrate approx. 2x of what I set in Edcast. (if I set 40kbs in Edcast, the stream is ~90kbs VBR)
Well, I tried it again and it seems to be pretty independent on the bitrate I set in Edcast. It is most likely defaulting to -V2 no matter what I do, I tried b=96, B=96, preset=CBR96, and it still results in ~200kbs VBR stream... it stutters because my internet connection is not so fast.
Hmmm, this is pretty puzzling. All my testing is done in CDex and both modified dlls perform exactly as expected. The only input acted upon within the dll code that is passed from the calling program is the input samplerate and the private, original, CRC and copyright flags. Everything else is set from the ini file, or uses defaults. Any more information would be helpful as I cannot reproduce this!
@jmartis: you may want to verify that the correct DLL will be loaded by using the dependency walker:
http://www.dependencywalker.com/ (http://www.dependencywalker.com/)
Regarding the Edcast Winamp 3.1.21 plugin: I have analyzed the file access made by "lame_enc.dll (3.98.2) modified to use INI File" and discovered that lame_enc.dll looks for the lame_enc.ini file in the ..\Winamp\Plugins folder. The reason for this discrepancy probably has to do with the calling plugin's location (..\Winamp\Plugins\dsp_edcast.dll) and Edcast's requirement to place lame_enc.dll in the Winamp root instead (..\Winamp\lame_enc.dll).
So to override Edcast's LAME settings, place lame_enc.dll in the root of ..\Winamp and place lame_enc.ini in ..\Winamp\Plugins.