Menu
▾
▴
1 Attachments
#471 Encoding comparison
Hi, I attach a simple spreadsheet with early results from my encoding comparison.
I compared files encoded by official lame 3.99.5 with those created by the latest 3.100 beta0 which should have the same psycho acoustic model inside.
Sources are wave PCM having 8, 11.025, 12, 16, 22.05, 24, 32, 44.1, 48 kHz sample rate.
Writing here because I suspect the mailing list will remove any attachment.
Comments/suggestions are welcome.
Can you try the VBR files again, with current CVS version?
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.New set of results.
These encodings (ever) show errors only on 16 kHz and 48 kHz source material.
Are this the same input files as in the first set?
Yes, exactly.
That is strange, that formerly identical files are now different. I don't think, that I've changed any CBR/ABR settings. A quick test with a 16 kHz sample, here the files are identical CBRs.
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.
Hm, what is the pcm format of your test files, float or int?
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).
So, LAME does some different float-to-int scaling as libsndfile?
Maybe we should fix that too.
I had a look at the source files of both projects.
It seems libsndfile, when importing float->int, calls
lrintf(intof2i_arrayandf2i_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.
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'm not sure, but eventually the floating point format allows to specify, at what value full scale is reached.
We are getting off topic here. Maybe we should keep these observations in mind for whatever comes after the 3.100 release?
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).
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).