I won't encode any album with 3.95+ unless I can disable the track gain tag which will possible destroy/interfere with my album (wave)gain (that I do before encoding) in the future.
Not to mention that it's wasting encode time.
Thanks
Full Version: LAME 3.95.1 Stable Released
I was unable to find a switch in parse.c to disable replaygain scanning. Is one planned in the next version?
I won't encode any album with 3.95+ unless I can disable the track gain tag which will possible destroy/interfere with my album (wave)gain (that I do before encoding) in the future.
Not to mention that it's wasting encode time.
Thanks
I won't encode any album with 3.95+ unless I can disable the track gain tag which will possible destroy/interfere with my album (wave)gain (that I do before encoding) in the future.
Not to mention that it's wasting encode time.
Thanks
QUOTE(getID3() @ Jan 14 2004, 06:31 PM)
Would you recommend --preset cbr 128 to anyone for anything?
Not for killer samples like fatboy, velvet and harpsichord, but apart from those...
I'm just onto Roberto's 128k mp3 test samples (which are probably not the easiest to encode), and uh.. what can I say, I'm not overly successful in finding artifacts with my headphones and loud volume.
I'm seriously reconsidering my "128k is utter crap that has to be deleted instantly" attitude that I got on this forum.
Try yourself before getting the flamethrower
QUOTE(sony666 @ Jan 14 2004, 12:24 PM)
I was unable to find a switch in parse.c to disable replaygain scanning. Is one planned in the next version?
I won't encode any album with 3.95+ unless I can disable the track gain tag which will possible destroy/interfere with my album (wave)gain (that I do before encoding) in the future.
Not to mention that it's wasting encode time.
Thanks
I won't encode any album with 3.95+ unless I can disable the track gain tag which will possible destroy/interfere with my album (wave)gain (that I do before encoding) in the future.
Not to mention that it's wasting encode time.
Thanks
If you wavegain or --scale the file before/during encoding, the replaygain value stored will just be the track variance from the album norm, which i think is still a useful value to have around. How will it interfere anyhow when there are no programs which read it?
QUOTE
if you look under help and it says something about "recommended", implying "better quality than default", then it should have a good-quality
You assume too much.
Recommended in my opinion should be what the majority of lame users are looking for.
QUOTE
do you really think so? Most people who actually go to the trouble of locating or compiling LAME, and then using it from a command-line, are also probably interested in making quality MP3s. I'd say make --preset standard the recommended, then let people choose CBR if they insist.
Take a look at Kazza, WinMX, & most other file sharing programs, 99% of the people use 128kbps CBR MP3's (lame is growing) which means they are happy with 128kbps CBR MP3's probably for the reasons I mentioned & what ever others.
Maybe a recommended normal MP3's, recommended archive quality MP3's & a recommended fast MP3's
QUOTE
Would you recommend --preset cbr 128 to anyone for anything? I didn't think so.
Can I answer now?
If a friend asks me to encode MP3's it is most of the time for hardware playback, MP3 car stereo, MP3 Discman, MP3 DVD player or similar hardware devices I would definitely & do use --preset cbr 128 because I know that's what they want however if asked I do let them know that there are options for achiving a higher quality I also would very rarely recommend VBR mp3's because of sync issues, track length issues, & just not being supported correctly by many hardware players.
QUOTE(getID3() @ Jan 14 2004, 11:31 AM)
Would you recommend --preset cbr 128 to anyone for anything?
Flash-based portable players?
There are still quite a few of those around.
Or portables of any kind, let me tell you my experience: I recently made a 13-hour trip to the American-Mexican border. I wanted to travel light, so I made a CD for my portable filled to the rim with 128CBR transcodes from my HA-approved-encoding-collection. It was a car trip, so I could never tell the difference, and it did not matter.
128 CBR still has its uses and it is an acceptable choice for many people for many uses. Just ask Roberto about it.
QUOTE
I won't encode any album with 3.95+ unless I can disable the track gain tag which will possible destroy/interfere with my album (wave)gain (that I do before encoding) in the future.
Not to mention that it's wasting encode time.
Not to mention that it's wasting encode time.
It will not interfere with anything. First of all, it is just a tag, and the value is not actually applied to the content. Second, the value is specified to be track gain, and not album gain. So if a player uses this value, it will act the way you want: if you configure it to use album gain, why would it use track gain?
QUOTE
Not to mention that it's wasting encode time.
Right, but it won't change your life: it is just 5%
Gabriel, just wanted to ask you about a possible extension of the replaygain feature in future versions. High Fidelity suggested to include the possibility to actually apply the calculated gain change to the audio in this thread:
http://www.hydrogenaudio.org/forums/index....topic=17468&hl=
His suggestion was to do it prior to actual encoding, like using wavegain and -scale manually. My suggestion was to do it the "MP3gain way" by changing the gain field (or whater it is called) after encoding.
Would it be possible to implement such an optional feature in either of the two ways suggested and if so would you consider it for future versions? The purpose would of course to get replaygain for portables etc.
http://www.hydrogenaudio.org/forums/index....topic=17468&hl=
His suggestion was to do it prior to actual encoding, like using wavegain and -scale manually. My suggestion was to do it the "MP3gain way" by changing the gain field (or whater it is called) after encoding.
Would it be possible to implement such an optional feature in either of the two ways suggested and if so would you consider it for future versions? The purpose would of course to get replaygain for portables etc.
QUOTE
Would it be possible to implement such an optional feature in either of the two ways suggested and if so would you consider it for future versions? The purpose would of course to get replaygain for portables etc.
I think that Mp3Gain is quite appropriate for this task.
Thanks for your response Gabriel
Although i am aware that the chances of the LAME RG tag doing anything at all are slim, I would still prefer not to have it. Some "smart" (hardware?) player might decide to use it someday without the option of ignoring it.
LAME has so many switches, one more can't hurt
I will trade you the depricated --mp1input which is still there for it, please 
Although i am aware that the chances of the LAME RG tag doing anything at all are slim, I would still prefer not to have it. Some "smart" (hardware?) player might decide to use it someday without the option of ignoring it.
LAME has so many switches, one more can't hurt
I will trade you the depricated --mp1input which is still there for it, please
Does anyone know if RazorLame or EasyLame will be ever be updated?
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.