Activity for LAME (Lame Aint an MP3 Encoder)
-
Bernhard Doebler posted a comment on ticket #517
Seems to me, these functions were introduced in -r6528
-
undeclared function id3tag_set_comment_ucs2 and id3tag_set_fieldvalue_ucs2
-
maikmerten posted a comment on ticket #516
Here's another patch approach: This makes -q4 the lowest quality setting (providing the best quality) for CBR and ABR. This is similar how for the new VBR mode, some quality settings are disallowed as well (a few lines prior).
-
The problem of q0/q1/q2/q3 producing worse results for CBR/ABR was introduced with this change: https://sourceforge.net/p/lame/svn/6147/ This enabled the new VBR-psymodel for CBR and ABR, which happened to help with https://sourceforge.net/p/lame/bugs/392/ (which also is about lower speed settings introducing artifacts).
-
ABR seems to be affected similarly to CBR. Here's a slightly expanded trivial patch to disable noise_shaping_amp for ABR as well.
-
Glenn Richards posted a comment on ticket #85
HDCD isn't an "audio format" as such; it's an encoding that's applied to PCM data, with in-band signalling used to indicate when the encoding is applied. Essentially it encodes the top and bottom 4dB of range using a logarithmic scale, increasing the apparent dynamic range to 20-bit but folding it into a 16-bit sample. Unfortunately there are very few players out there which can decode it. My old Arcam DV79 would, but only via the analogue out (the HDCD decoder needs to be in the DAC). There were...
-
Elio Blanca posted a comment on ticket #85
Currently lame provides native support for a bunch of uncompressed audio formats (WAV, AIFF, RAW...). External libmpg123 provides support for mpeg audio formats, and libsndfile does so for further compressed/uncompressed formats. Now, the best place for libhdcd inclusion would be the latter, so in a glance you will get hdcd format supported in a whole range of different applications (including lame). The devs are also quite reactive.
-
HDCD decoding support
-
Here's a trivial patch that sets noise_shaping_amp to 0 for CBR encoding.
-
For some reason, I accidentally filed this in group "Compatibility". More fitting would be "Quality", of course.
-
CBR: High quality settings (e.g, -q 0) degrade quality over -q 4
-
beatmaster posted a comment on ticket #59
Hello Alexander! Are you planning to release a final version this year? (e.g., 3.200)
-
thomas kaeding posted a comment on ticket #515
Also seen in comment 3 on this page: https://bugzilla.redhat.com/show_bug.cgi?id=1505107
-
mp3x --enable-dynamic-frontends fails to compile
-
PassionateUser posted a comment on ticket #452
https://svn.code.sf.net/p/lame/svn/trunk/lame/USAGE If not specified, LAME may sometimes resample automatically when faced with extreme compression conditions (like encoding a 44.1 kHz input file at 32 kbps). To disable this automatic resampling, you have to use --resamle to set the output samplerate equal to the input samplerate. In that case, LAME will not perform any extra computations. Letter p is missing in --resamle flag here.
-
Alexander Leidinger posted a comment on ticket #59
Hi, 3.100 is the latest official source code release (here on sourceforge). There is no official binary / executable download from the lame project (legal reasons). As we don't maintain any official binary / executable download site, we can not really comment on what is available outside our influence. Bye, Alexander.
-
Martin Fessler created ticket #59
Which is the latest version? 3.100? 3.100.1?
-
lamime.c fails to compile under cygwin64 - lametime.c:139:25: error: ‘_O_BINARY’ undeclared
-
Fixed in SVN.
-
Qwerty Asd posted a comment on ticket #451
It works. Thanks!
-
Use suitable typedef for Windows.
-
Use better return types and provide prototype for toUtf8().
-
Fix UTF8 id3tag support.
-
Unbreak UTF8 genre tag. Text tags still broken.
-
Unbreak UTF8 genre tag, text-tags still broken (wrong encoding).
-
Try to provide a toUtf8() function for Windows.
-
increase beta patch-level after todays changes
-
need autogen.sh for easy building
-
The autotools contains "autoreconf" which helps. The script in attachment wasn't complete, it depends upon some gnome stuff.
-
Adding IPV6 support to mp3rtp utility
-
Commited. There were some changes since then, so parts had to be applied by hand. I did some very very light testing. Can you test?
-
regen
-
regen
-
Add IPv6 support for mp3rtp.
-
pkg-config support and some tab to spaces
-
pkgconfig support for libmp3lame
-
Patch from Debian committed.
-
regen
-
fix variable name
-
regen / modernize with newer autotools
-
regen / modernize with newer autotools
-
regen / modernize with newer autotools
-
regen / modernize with newer autotools
-
rename to current convention and modernize with newer autotools
-
modernize with newer autotools
-
modernize with newer autotools
-
modernize with newer autotools
-
modernize with newer autotools
-
Add pkg-config support.
-
We have a VS 2019 project file in the tree since a while. Does this work better?
-
I'm not a lawyer, but I think the LGPL would be satisfied if you use dynamic linking (I suggest together with the info on which lame version or svn revision this is based on).
-
support for ID3v2.4 (UTF-8)
-
Patch #99 committed. Some testing is needed.
-
support for ID3v2.4 (UTF-8)
-
Committed. With some code in the frontend to use it. Could you please check/test and see if this is ok (the frontend uses iconv to convert the characters if needed)?
-
Add ID3v2.4 support (UTF-8) to libmp3lame.
-
kris posted a comment on ticket #84
I have taken a stab at adding support for UTF-8 ID3v2.4 tag and posted my patch here: https://sourceforge.net/p/lame/patches/99/#aad8
-
I have taken a stab at adding support for UTF-8 ID3v2.4 tag - see the ID3v2.4_UTF8_support.patch file attached. Some details below. Background as I understand it The ID3v2.4 is the first ID3 tag version to explicitly support UTF-8 encoding - it is done by specifying 0x03 value for the encoding byte. The encoding byte of 0x00 indicates ISO-8859-1 (latin-1) encoding. For context, there are 3 versions of ID3 metadata tags at play here: ID3v1 - doesn't explicitly support UTF-8. Seems like you can use...
-
Sylvain Carette created ticket #514
Current version of lame do not build for android
-
David M. Cotter posted a comment on ticket #84
I, too, would be interested in this happening.
-
Apologies, meant to post this as a feature request. Did so here: https://sourceforge.net/p/lame/feature-requests/84/
-
support for ID3v2.4 (UTF-8)
-
support for ID3v2.4 (UTF-8)
-
Fabian Greffrath posted a comment on ticket #42
Debian now patches this into their packages: https://salsa.debian.org/multimedia-team/lame/-/blob/master/debian/patches/pkg-config.patch
-
Van de Bugger created ticket #98
Return non-zero exit status if reading the input mp3 file failed.
-
I prepared a patch which solves this issue. See attachment.
-
lame produces invalid result while exit status is zero
-
Mark Esler posted a comment on ticket #477
As Salvatore points out, this issue (CVE-2017-15019) appears to be addressed with https://sourceforge.net/p/lame/svn/6386/tree/trunk/lame/mpglib/interface.c?diff=59e1c885dab7b929b5817e2e:6385
-
Latest time I needed the lame DLL (many years ago, truth be told) I used a mingw environment and the configure script as well, as the static library libmp3lame.a is needed indeed. Well, I think I used the script Makefile.mingw32 located into Dll/ subdir, this created the file "BladeMP3Enc.dll" which I renamed into lame_enc.dll . Give it a try/play with it, everything you need is there.
-
Rajat Aggarwal created ticket #58
Building LAME 3.100 on windows
-
jovy created ticket #512
lame.exe clips content over 0dB (32bit wav float)
-
Felix Droop posted a comment on ticket #510
Do I understand it correctly that all versions will then produce values like my current Windows version? It is good that the values don't differ, but for me the files generated with my current Linux version, which is linked against libsndfile, worked well with the programs I use and the files from the Windows version were too quiet. Wouldn't it be desirable to bring the current Linux (+libsndfile) behavior to the (Windows) versions without libsndfile?
-
There is a pull request I created some time ago, which is still waiting for Erik to merge, extending this default behaviour when the caller application doesn't want to apply any amplitude modification to the audio source: https://github.com/libsndfile/libsndfile/pull/314 this patch will hopefully prevent the replay gain discrepancy.
-
You were right, unsupported audio format error for my Windows version and no problems with my Linux version.
-
As a trivial check, feed lame with a flac encoded file. libsndfile can decode flac, plain lame can't. (my bet: linux distributions always link against libsndfile)
-
Julio Jose created ticket #511
Wrong NonDelegatingInterface in OutputPin of LAME Directshow filter
-
The sample format is float32. I don't know whether the executables are linked against libsndfile and I honestly don't even know how to find out. For windows I got the LAME 3.100 64bit package from RareWares. It seems to only contain the lame_enc.dll. On Linux I got it via apt.
-
Which is the sample format for the source wav file? integer? float? bit depth? is any of both lame executables linked against libsndfile ? Libsndfile DOES amplify the source content when picking a file encoded as floating point.
-
ReplayGain values on Windows and Linux differ
-
Compiler Error
-
Should be fixed in the most recent SVN version.
-
Frontend fails to build.
-
Committed. Thanks!
-
Fix build on cygwin with configure options --disable-static --enable-shared --disable-decoder.
-
Fix build on riscv64/FreeBSD
-
Committed. Thanks!
-
Fix build on FreeBSD riscv (replace compile time arch detection by feature detection).
-
Carlo Bramini posted a comment on ticket #97
The patch.
-
Frontend fails to build.
-
Robert Clausecker created ticket #96
Fix build on riscv64/FreeBSD
-
Josep Maria Antolín Segura posted a comment on ticket #509
This is expected behaviour. LAME reduces the volume on input. By default it applies "--scale 0.97", which reduces the volume slightly. This default was implemented long ago, in order to prevent some distortions on some samples when decoding. Nowadays, using decoders that either output in floating point and/or apply replaygain previous to clipping the audio to integer already solves the problem, so in that case, using --scale 1.0 should give what you want without a negative impact.
-
Dave Perry posted a comment on ticket #509
Yes. If I take a reference file in Audacity, which I believe uses LAME for mp3 encoding, and export the file as Mp3 and Wav. The Mp3 files measure about 0.4db quieter than the Wav version and original file. If I perform the same test in other DAWs that uses LAME the results are the same. If I perform the test in Pro Tools which uses Fraunhofer IIS encoder the results produce the same level file regardless of if it is an Mp3 or Wav output. Kind regards, Dave On Tue, Jun 8, 2021 at 11:14 AM Elio Blanca...
-
Can you provide more details in order to make the issue repeatable?
-
LUFS levels differ exporting mp3 over Wav
-
Samuel Hong created ticket #508
Compiler Error
-
Michael Tarantelli created ticket #507
No Windows Installation File
-
bump to beta 2
-
Fix some issues with clang build.
-
Remove the part about NDEBUG, we use existing asserts as a quick and easy way to prevent bad input to cause issues.
-
Source package release for Hip?
1 >