Activity for Elio Blanca
-
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.
-
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.
-
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.
-
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)
-
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.
-
Can you provide more details in order to make the issue repeatable?
-
Attaching new version of the same patch. Should patch#83 ever be merged, this would became critical (it is useful even now, though).
-
In practice, this is VERY hard to achieve. On the first hand, MPEG audio Layer III allows for any frames to keep some room for data belonging to upcoming frames, in order to give them more bits (and more quality in the end). This is called 'bit reservoir' and this makes the frames from the beginning of your second file different from the last frames at the end of your first file, as the latter don't need to keep any room because they don't have any upcoming frames. On the other hand, lame allows...
-
Those are actually good points, so good it would be a pity getting them lost into a (soon-to-be-closed) ticket. Anyone willing to take them and develop solutions would be greatly helped by finding such a guide - I see all this post deserves to be pasted into a (revised?) TODO, shipping with the lame tarball. What do you think?
-
This is to make lame abort the encoding when it encounters bad input, instead of generating garbage. If we would revert that part, we will open up the executable to buffer overflow issues. Maybe I'm a bit hard to understand but, should different problems be solved using different approaches? If one feeds lame with garbage, then lame will create garbage, but it's OK, this is not lame's responsibility - it's just an encoder. On the other hand, do the buffer overflow issues still apply after the many...
-
Gosh, you are right. The problem is the file itself. I'm getting worried about this SSD, never had such a problem on an 'old' hard disk drive. Thank you.
-
Data error during compression
-
This is exactly what option '-r' does. From the Changelog: lame music verification. A crc16 calculated over the whole audio bitstream is also stored into the tag, so this is now used to validate the audio data. Due to byte reflection, the computation is quite slow, so this is disabled by default. You can force it with command line switch '-r'.
-
Print svn revision among version info
-
Just tuned the lowpass frequency when encoding CBR at 320 kbps and I got a different spectrogram. The patch is simple as this: diff -ur lame-svn-r6448-trunk-lame_orig/libmp3lame/lame.c lame-svn-r6448-trunk-lame-1/libmp3lame/lame.c --- lame-svn-r6448-trunk-lame_orig/libmp3lame/lame.c 2019-06-28 15:05:47.000000000 +0200 +++ lame-svn-r6448-trunk-lame-1/libmp3lame/lame.c 2019-07-26 11:13:22.802316849 +0200 @@ -227,7 +227,7 @@ {192, 18600}, {224, 19400}, {256, 19700}, - {320, 20500} + {320, 24000} };...
-
Still same behaviour using lame svn-r6448. Spectrogram attached.
-
After a test session, it seems that you have fixed the issue. The assertion never fails, anymore - great! lame built with both clang and gcc, both with NDEBUG patch and not. In case of gcc, also with both version detection fixed and unfixed in configure.in.
-
I think I'm goin' off topic targeting scalefactor consistency... Back to 'ABR_iteration_loop', the issue is too many bits are consumed when encoding a particular frame. No surprise, as the provided data is built on purpose to break the library. What this routine does as the very first step is calculating the target bits, as a forecast of the allocated bits for any channels, and for each granule (four values at most). Surprisingly, the forecast is NOT ALWAYS targeted, as sometimes the allocated bits...
-
I'm running backwards in search of the root cause for some different result. My current scenario has gcc as the only compiler and configure.in with NDEBUG commit reverted. Using all this as a base, I can make the assertion fail/not fail disabling/enabling GCC optimization (into configure.in). Despite my previous post (due to my messy build environment), enabling the GCC optimization makes the assertion NOT to fail. Step one: into 'calc_noise' (quantize_pvt.c) I added some useful printf in the beginning...
-
Hacking 'ABR_iteration_loop'. The assertion fails at the ninth call of this, so I tried to tweak this a bit, in particural about the call to 'calc_target_bits'. First attempt was reducing the amount of target bits already evaluated (only at the ninth call). After the call to 'calc_target_bits', decreasing the values by 2 results in no more assertion fails. In a different code branch, I tried modifying cfg->compression_ratio which is used into 'calc_target_bits'. Only at the ninth cycle, adding 1.5...
-
Setting highest warning level (-Wall -Wextra) for libmp3lame resulted in very few warnings, some about unused variables, some others due to shift of a negative value. On my system sizeof(int)=4 Further, when using -fno-strict-aliasing and -fno-aggressive-loop-optimizations I didn't get new warnings, and the user provided code still makes the assertion fail.
-
I'm on a x86_64 distro (LMDE3), compiling native lame with gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 and binutils-2.28 and during configure (--enable-nasm) I see the library has no asm optimizations for my architecture, so I'm assuming only C code gets compiled. Sorry, just forgot to mention those details.
-
Even without patching configure.in for gcc (that is, without gcc optimizations) the assertion fails.
-
I will report what I did, in order to make the assertion fail. 1: lame svn 'vanilla' built with gcc: no fail. 2: lame svn with reverted commit r6323 (NDEBUG related) AND configure.in patched for enabling gcc optimizations: assertion fails. 3: lame svn 'vanilla' built using clang: assertion fails. I'm currently using the second scenario.
-
Which version of libmp3lame are you linking against? OS +version ? compiler +version ? linker +version?
-
Sorry for this late reply. You could just use '>>' instead of '>' and you will have all the output file opened in append, not overwrite mode.
-
Performed the same test on my pc. $ sox -V3 -r 44100 -b 24 -n -c 2 x.wav synth 10 sin 10+22000 remix 1p-1 channels 2 (created x.wav) Then encoded using the latest lame svn6437 : first, CBR $ frontend/lame -q 0 -b 320 x.wav xc.mp3 LAME 3.100.1 64bits (http://lame.sf.net) Using polyphase lowpass filter, transition band: 20094 Hz - 20627 Hz Encoding x.wav to xc.mp3 Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (4.4x) 320 kbps qval=0 Frame | CPU time/estim | REAL time/estim | play/CPU | ETA 384/384...
-
This project releases lame in source code only, not exe/dll. The author(s) of your build will be able to support you better.
-
Finally, this is due to an unfortunate sum of both issues. Using information from both this thread and the ML, the lame executable is supposed to have a noticeable speed boost.
-
The LAME project is made of two components. 1: the libmp3lame which is a software library used to encode layer3 streams 2: the lame frontend, which calls functions from libmp3lame in order to write layer3 streams as output. Further, the lame frontend is able to decode mpeg audio streams using a decoding library, mpglib. As your request is "How to decode file stream in C++ with libmp3LAME", my understanding is you need libmp3lame for audio decoding, and my answer is NO, it can't. Use functions from...
-
What libmp3lame does is encoding, that is the library creates a layer3 stream when you feed it with uncompressed samples. It seems your need is the opposite, so you should pick a decoding library (such as mpg123, used by lame itself for decoding) and link it to your application.
-
Tiny little fix for my latest Makefile
-
New test session: same lame 3.100.1 svn 6432, NDEBUG commit reverted, then launched "autoconf" to get new configure. I took care not to define NDEBUG in my environment. Same hardware, same distro. --preset extreme 3.99.5 40.8x 3.100.1 47.3x -q 0 -V 0 3.99.5 41.1x 3.100.1 47.5x -q 0 -V 0 -m s 3.99.5 45.6x 3.100.1 53.8x -q 0 -b 320 3.99.5 11.4x 3.100.1 11.6x -q 0 -b 320 -m s 3.99.5 11.7x 3.100.1 12.0x [the encodings seem surprisingly faster now but this is actually due to a heavy x265 encoding in background...
-
I reverted the NDEBUG-related part of that commit, I did run 'autoconf', then ./configure & make. Further, in my environment I set CPPFLAGS="-DNDEBUG" This build of lame 3.100.1 encodes my test wave file at 28.5x (several runs, of course) The lame-3.99.5 shipped with ubuntu 16.04 encodes the same file at 26.0x. So, you cought the point! And the latest lame achieves better result too. I want to perform further tests, where I won't set the environment CPPFLAGS and see how fast the build will get. Up...
-
I reverted the NDEBUG-related part of that commit, I did run 'autoconf', then ./configure & make. Further, in my environment I set CPPFLAGS="-DNDEBUG" This build of lame 3.100.1 encodes my test wave file at 28.5x (several runs, of course) The lame-3.99.5 shipped with ubuntu 16.04 encodes the same file at 26.0x. So, you cought the point! And the latest lame achieves better result too. I want to perform further tests, where I won't set the environment CPPFLAGS and see how fast the build will get. Up...
-
Disable bitstream padding
-
Take advantage of terminal width on printing file names
-
Mmmhhh, maybe there's more. In my environment (ubuntu 32 and 64 bit distros) setting the macro NDEBUG during the build didn't change anything and the speed difference is still noticeable.
-
I did a series of tests on my own, and I can confirm this. On ubuntu 64 bit I have lame-3.99.5 running at 44x, lame-3.100 runs at 21x. On an old ubuntu 32 bit, almost the same results. This indeed is a big difference, and it happens regardless of nasm usage. I performed a run of gprof on both lame versions (nasm enabled) and cut & paste the relevant part, attaching report. The first noticeable thing is a big increase in execution time for the "k_34_4" routine, almost 1,5x slower. Rather, other routines...
-
Anyway, I see your latest commit r6426 fixed this bug. This ticket may be closed.
-
Yes I am, on x86 debian this bug doesn't appear.
-
Wrong wave parsing
-
Small speed-ups into util.s
-
This should be fixed now in svn, please get the latest source and report your results.
-
Fix for completing svn-r6410
-
It seems both lame and mpg123 decode your file taking into account the lame tag, so they both cut away the heading encoder delay and the encoder padding (at the file end). I would say they are the most precise decoders in this whole series. The 3816 sample discrepancy is easily explained, as 3816=576+2088+1152. 576 is the amount of encoder delay, these samples should be discarded. 2088 is the amount of encoder padding, these samples should be discarded as well. 1152 is the amount of samples into...
-
It seems both lame and mpg123 decode your file taking into account the lame tag, so they both cut away the heading encoder delay and the encoder padding (at the file end). I would say they are the most precise decoders in this whole series. The 3816 sample discrepancy is easily explained, as 3816=576+2088+1152. 576 is the amount of encoder delay, these samples should be discarded. 2088 is the amount of encoder padding, these samples should be discarded as well. 1152 is the amount of samples into...
-
Actually, the packages may be downloaded on another PC and then copied into var\cache\mingw-get\packages so the mingw-get executable may find them but the very first step, the catalog update, has to be done on line AFAIK.
-
I think the relevant information here is Length of original audio : 14207256 samples do your decoded files match this size? If the used decoders do not take into account the tag contents, then the resulting file may be larger (it still contains delay and padding samples). Also, based on madplay output, I can figure out some (not serious) corruption perhaps happened into samples area of the very first frame.
-
Before trying any fixing, some further diagnostics may be useful. Try decoding the file with madplay (here an old windows build) and check the resulting wave. Also, analyze the file with mp3guessenc and post its log.
-
Lame is being updated since 3.99.5 and version 3.100 will soon be released with many fixes, also mpglib related. Give it a try. Having said that, mp3 decoding is not the main purpose of lame, there are already several tools for that, such as madplay or mpg123, how they behave with your troublesome input file?
-
I recently submitted a patch for libsndfile in order to disable auto scaling for floating point input files, and seems Erik will merge it into the library. Hopefully in a couple of days this feature will be into the library. Then lame will be able to disable auto-scaling (when using a recent enough libsndfile).
-
Are you sure this can happen in a real case? Before calling lame_get_num_channels, you have to call the similar lame_set_num_channels, this only allows setting 1 or 2 as valid channels. Further, when a valid library init is performed, gfp is always a valid pointer. Also, in current CVS code you can find a check against not allowed values (including channels).
-
Are you sure this can happen in a real case? Before calling lame_get_num_channels, you have to call the similar lame_set_num_channels, this only allows setting 1 or 2 as valid channels. Further, when a valid library init is performed, gfp is always a valid pointer.
-
I partially agree. We already know current lame-3.100 creates the same bitstreams 3.99.5 did, but on the other hand, there's this new issue of libsndfile changing input values. That is, when lame is built with libsndfile support (as any normal distro does) AND the encoded audio is floating point, THEN the resulting bitstream is altered. This is worth a mention (or a fix, eventually).
-
Maybe there's more. It seems libsndfile is amplifying its input values when importing floating point samples (they get full scale at most), so asked Erik for details.
-
I had a look at the source files of both projects. It seems libsndfile, when importing float->int, calls lrintf (into f2i_array and f2i_clip_array) instead lame uses simple rounding as int i=(int)(float*scale + 0.5) Further, I find it suspect that lame uses two different scales for positive and negative numbers (into frontend/get_audio.c#1267 and forth). Libsndfile does not.
-
Oh-oh! You caught the point! They are all 16 bit int, except for 16 kHz and 48 kHz samples which are 32 bit floating point (didn't notice this before). After converting both them into 16 bit int samples, they make lame-3.100b pass the test as well (with AND without libsndfile support).
-
Here's the new report. Now every single bit matches the output of 3.99.5 "vanilla". I did a mistake yesterday and picked a lame executable built without libsndfile support. The wrong comparison was between lame-3.99.5 (with libsndfile) and lame-3.100b (without libsndfile). Pretty odd this only affected 16 kHz and 48 kHz content, by the way. Today I did the comparison: lame-3.99.5 (with libsndfile) vs lame-3.100b (with libsndfile) and so the results match.
-
Yes, exactly.
-
New set of results. These encodings (ever) show errors only on 16 kHz and 48 kHz source material.
-
This is already fixed in CVS code, where a nullterminator is always added at the string end. The statement outPath[PATH_MAX-4] = '\0'; is added after the strncpy instruction. Edit: further, about inPath and outPath there is no danger. They both are two PATH_MAX-sized arrays, so they are sized to the max name length the current file system can support.
-
This is already fixed in CVS code, where a nullterminator is always added at the string end. The statement outPath[PATH_MAX-4] = '\0'; is added after the strncpy instruction.
-
Yes, I will try it later. Anyway, a further session with my current build (it is a couple of days old) gives me new information: adding switch --resample X (with X being the same as the input file frequency) to the command line causes some of those FAIL to become OK. So, the bitstreams are then identical.
-
Encoding comparison
-
Unable to build without mpglib
-
The dark side of the (IT) moon
-
The most simple fix is indeed validating the number of channels before store. I applied this fix in a branch of my lame 3.100a2 repository at https://github.com/eblanca/lame/tree/fix_num_channels . Further suggestions are welcome.
-
Break?
-
Break?
-
You're right, I was misleaded by the hex available values of _WIN32_IE following...
-
Shell_NotifyIcon support macros
-
Thank you Keith. Now, I see those 64 bit types (both __off64_t and off64_t) are defined...
-
Honor _FILE_OFFSET_BITS no more
-
At this moment, formatting output strings in JSON or XML is quite a big work. On...
-
Ancient Melodies are here...
-
News under the hood
-
Guess what??? Again!
-
Hotel Torino is here!
-
Snow time, release time!
-
mp3guessenc 0.25.1 released!
-
Unexpected hassle behind a simple idea
-
Unexpected hassle behind a simple idea
1