so what to expect for lame 4?, and all about it Options

[adlai]

so, I have a few questions about LAME 4.

1. Who's developing it? LAME devs? Or wasn't some Japanese guy doing it?

2. If it's the future, why are other LAME versions being released?

3. what sort of quality will it be? from what I've seen, it's supposed to be really fast... which is nice, but that wouldn't matter if it's quality were not as good as 3.90.3

4. when will it come out?

[john33]

The current TODO list from the LAME 4.0 source:

encoding core:
1.
LAME has problems with test signals.
1. pure DC input.(i.e. a square wave with a frequency well below 20 Hz)
2. sin sweep signal (i.e. 20Hz->22kHz in 60sec)
3. steep/saw wave (i.e. 100Hz)
Seems not very important, but they are related to "REAL" problem of
some kind of music. 1 and 2 are caused by ATH handling problem.
3 is by short block threshold problem.



2.
To prevent the lower frequency uncertainness (because of FFT length),
we should add the some highpass filter(cut < 20Hz or so) before
psycho-analysis.


3.
Some switches to support the "BUGGY" decoders.
--strictly-enforce-ISO is not perfect to these players.

--sameblock  : forcing to use coupling block type (implemented),
                for some DVD players
--lesserixmax : reduce IXMAX_VAL (not yet), for old winamp.

it seems we do not need --noscfsi or --noscalefac options. That's good news.


4.
short block encoding quality problem

At the high frequency region, LAME4 increases the threshold too much.
And more the worse, there's sfb21


5.
Tag problem.
Still there're some tag problems between VBR(LAME) tag and MS-Windows.
Clipping detection/replaygain tag is supported LAME3.x, but LAME4 does not.



8.
low bitrate quality problem and better intensity stereo support.
and LAME4 should support i-stereo even when MPEG2 Layer3 (currently not).

Note: mpg123 (and all derivatives, like xmms and lame/mpglib)
have bugs in the intensity stereo decoding.  Bugs have been there
for years since there are very few intensity stereo mp3's out there.




9.
We should rewrite all the documentation, such as INSTALL, README*,...


11.
Tuning reservoir handling (especially for low bitrates); CBR arround
90kbps (-b 90) is worse than VBR quality 7 (-V 7). This is probabry
because of poor resorvoir handling.

Right now the code is tuned with the LAME3's pe calculation and
psymodel. Now they are all changed and we should re-tune these code.

2-pass VBR/ABR will perfectly solve the problem, but before it,
we should improve the 1-pass encoding.

And about ABR, it should be removed and new "VBR but some constant bitrate"
algorithm, IMHO.



10.
over 2^31 byte cleaness (especially header handling).


15.
LAME has a 31 point FIR filter used for resampling, which
can also be used as a lowpass.  When resampling is done,
use that filter to also lowpass instead of the polyphase filter.


16.
Even when resampling is not needed, should we use an FIR filter
for the lowpass?  If it is not too much slower, yes.  If it
is slower, then it should be an option since it will produce
higher quality. 


17.
better highpass/lowpass filter:
We need to first replace the polyphase filter with an FIR filter.
And setting highpass filtering to enhance the playback frequency range.


20.
Replacing the resampling code of ssrc (Shibatch sampling rate conv.)
will bring better result. But ssrc only supports some specific frequencies.

So we should use both of ssrc/old resample code...


25.
mp3x does not work at all when the input is too short.



40.
mp3x cannot display subblock of short blocks correctly.



50.
Better tonality estimation.
Nspsytune seems to miss tonals when several of them are too narrow.
maybe nspsy2 based model will solve it.



70.
Use mixed blocks.




998.
Merge GOGO's fast assembler routines.




decoding support.
1.
mp3 decoding is not reentrant nor thread safe.

2.
mp3 decoding support code has poor error recovery.

3
mgplib has bugs with i-stereo.  flag denoting invalid
i-stereo value (= frame is m/s stereo) is not correct.

4.
modify mpglib to output floating point and have finaly quantization
step a easy-to-change module so it can output other than 16bit.
(replace mpglib with MAD?  MAD has agreed to write a call back
which will return all data needed by the frame analyzer)






NOGAP encoding:

-nogap:  more testing, fix options, test id3 tags?
Can we change id3 tags without reseting the encoder??
At the end of encoding 1.wav, call lame_get_mf_samples_to_encode()
to find the number of non encoded buffered PCM samples.  Then
encode samples from 2.wav until these PCM samples have been
encoded, *THEN* call lame_encode_flush_nogap() and close
out file 1.mp3.


NOGAP decoding: 
lame --decode --nogap file1.mp3 file2.mp3 file3.mp3
should also work.  What needs to be done:
get_audio.c:  We need a way to open a second mp3 file, without
              calling lame_decode_init() and reinitializing mpglib.
              And the mpglib needs to know to look for new Xing
              tags at the beginning of file2.mp3 and file3.mp3.


frontend code:

1.
raw file format and options.
--signed, --unsigned, --little-endian and --big-endian do not work correctly.

2.
Code is a complete mess. But it has so many debugged features it will
be a lot of work to re-write.

999.
It would be nice to save some information whilst encoding when
wave <-> mp3
a RIFF/wave can contain LIST chunks with information
about author, title, etc.
id3tag in mp3 can contain these information, too.

auto converting each of them may be good.



Build environment
1. MSVC .net solution files.

2. more 64 bit environment support.

3. check the "HACKY and FAST" code on many environments. They are
really fast, but are not confirmed to run on all environments.

4. NASM version check. LAME4 needs nasm 0.98.38 (or maybe upper).



ACM
see ACM/TODO file