xref: /third_party/lame/TODO (revision 159b3361)
1159b3361Sopenharmony_ci1.  bug in resample code:  downsampling from 44101 to 44100 causes
2159b3361Sopenharmony_ci    a seg fault.  Workaround in place for now:  resampling disabled 
3159b3361Sopenharmony_ci    if input/output samplerates agree to 4 digits.  
4159b3361Sopenharmony_ci
5159b3361Sopenharmony_ci
6159b3361Sopenharmony_ci2.  high bitrate encodings have trouble on some hardware players.
7159b3361Sopenharmony_ci    Track this down.  Probably caused by --strictly-enforce-ISO and
8159b3361Sopenharmony_ci    IXMAX_VAL.  Try setting IXMAX_VAL back to 8191 and/or
9159b3361Sopenharmony_ci    maxmp3buf=8*960 to see if there is a working combination.
10159b3361Sopenharmony_ci
11159b3361Sopenharmony_ci    note: one of the decoder bugs was identified. It is caused by using
12159b3361Sopenharmony_ci    different block sizes on both channels. A parameter need to be
13159b3361Sopenharmony_ci    added to Lame to handle workarounds.
14159b3361Sopenharmony_ci
15159b3361Sopenharmony_ci
16159b3361Sopenharmony_ci3   frontend: code is a complete mess. But it has so many debugged
17159b3361Sopenharmony_ci    features it will be a lot of work to re-write.
18159b3361Sopenharmony_ci
19159b3361Sopenharmony_ci
20159b3361Sopenharmony_ci4.  MSVC project files.  It would be nice to create a working
21159b3361Sopenharmony_ci    MSVC6 workspace, which included all the projects as possible
22159b3361Sopenharmony_ci    targets:
23159b3361Sopenharmony_ci          lame.exe
24159b3361Sopenharmony_ci          mp3x.exe   (require GTK libs)
25159b3361Sopenharmony_ci          lame_enc.dll   
26159b3361Sopenharmony_ci          ACM codec
27159b3361Sopenharmony_ci          directshow codec
28159b3361Sopenharmony_ci
29159b3361Sopenharmony_ci    I think the only MSVC5 project that we need to preserve is
30159b3361Sopenharmony_ci    for lame_enc.dll, since Albert Faber (still?) doesn't use VC6?
31159b3361Sopenharmony_ci    But no reason we cant have VC5 and VC6 project files for the dll.
32159b3361Sopenharmony_ci
33159b3361Sopenharmony_ci
34159b3361Sopenharmony_ci5.  NOGAP encoding:
35159b3361Sopenharmony_ci
36159b3361Sopenharmony_ci    -nogap:  more testing, fix options, test id3 tags?
37159b3361Sopenharmony_ci    Can we change id3 tags without reseting the encoder??
38159b3361Sopenharmony_ci    At the end of encoding 1.wav, call lame_get_mf_samples_to_encode()
39159b3361Sopenharmony_ci    to find the number of non encoded buffered PCM samples.  Then
40159b3361Sopenharmony_ci    encode samples from 2.wav until these PCM samples have been
41159b3361Sopenharmony_ci    encoded, *THEN* call lame_encode_flush_nogap() and close
42159b3361Sopenharmony_ci    out file 1.mp3.
43159b3361Sopenharmony_ci    
44159b3361Sopenharmony_ci    
45159b3361Sopenharmony_ci    NOGAP decoding:  
46159b3361Sopenharmony_ci    lame --decode --nogap file1.mp3 file2.mp3 file3.mp3
47159b3361Sopenharmony_ci    should also work.  What needs to be done:
48159b3361Sopenharmony_ci    get_audio.c:  We need a way to open a second mp3 file, without
49159b3361Sopenharmony_ci                  calling lame_decode_init() and reinitializing mpglib.
50159b3361Sopenharmony_ci                  And the mpglib needs to know to look for new Xing
51159b3361Sopenharmony_ci                  tags at the beginning of file2.mp3 and file3.mp3.
52159b3361Sopenharmony_ci
53159b3361Sopenharmony_ci
54159b3361Sopenharmony_ci6.  Does stdin work when LAME is compiled to use libsndfile? 
55159b3361Sopenharmony_ci    (new version of libsndfile will support this - try this out)
56159b3361Sopenharmony_ci
57159b3361Sopenharmony_ci
58159b3361Sopenharmony_ci7.  LAME has problems with pure DC input.  i.e. a square wave with
59159b3361Sopenharmony_ci    a frequency well below 20 Hz.  Not very important, but it should
60159b3361Sopenharmony_ci    be fixed.
61159b3361Sopenharmony_ci
62159b3361Sopenharmony_ci
63159b3361Sopenharmony_ci8.  mgplib has bugs with i-stereo.  flag denoting invalid
64159b3361Sopenharmony_ci    i-stereo value (= frame is m/s stereo) is not correct.  
65159b3361Sopenharmony_ci
66159b3361Sopenharmony_ci
67159b3361Sopenharmony_ci9.  lowpass filter: for M/S stereo, use more filtering for the side
68159b3361Sopenharmony_ci    channel, less filtering for mid channel.  We need to first replace
69159b3361Sopenharmony_ci    the polyphase filter with an FIR lowpass filter with finer frequency
70159b3361Sopenharmony_ci    resolution before implementing this. 
71159b3361Sopenharmony_ci
72159b3361Sopenharmony_ci
73159b3361Sopenharmony_ci10. LAME has a 31 point FIR filter used for resampling, which
74159b3361Sopenharmony_ci    can also be used as a lowpass.  When resampling is done, 
75159b3361Sopenharmony_ci    use that filter to also lowpass instead of the polyphase filter.
76159b3361Sopenharmony_ci
77159b3361Sopenharmony_ci
78159b3361Sopenharmony_ci11. Even when resampling is not needed, should we use an FIR filter
79159b3361Sopenharmony_ci    for the lowpass?  If it is not too much slower, yes.  If it
80159b3361Sopenharmony_ci    is slower, then it should be an option since it will produce
81159b3361Sopenharmony_ci    higher quality.  
82159b3361Sopenharmony_ci
83159b3361Sopenharmony_ci
84159b3361Sopenharmony_ci12. We should consider moving the experts options from the *long
85159b3361Sopenharmony_ci    help* text into an *experts only* help text. The average Joe gets
86159b3361Sopenharmony_ci    knocked down by the huge number of possibilities to setup lame.
87159b3361Sopenharmony_ci
88159b3361Sopenharmony_ci
89159b3361Sopenharmony_ci
90159b3361Sopenharmony_ci50. Better tonality estimation.
91159b3361Sopenharmony_ci    Gpsycho uses predictability, and so needs a delay to detect the tonality
92159b3361Sopenharmony_ci    of a sound.
93159b3361Sopenharmony_ci    Nspsytune seems to miss tonals when several of them are too narrow.
94159b3361Sopenharmony_ci    We would probably need the best of both.
95159b3361Sopenharmony_ci
96159b3361Sopenharmony_ci
97159b3361Sopenharmony_ci
98159b3361Sopenharmony_ci60. Different ATH handling for sfb21. We are using the minimum value of ath
99159b3361Sopenharmony_ci    in each whole sfb. in sfb21 this leads to very high bitrates.
100159b3361Sopenharmony_ci    We could perhaps use 2 or 3 ath partitions in sfb21
101159b3361Sopenharmony_ci
102159b3361Sopenharmony_ci    note: partially done
103159b3361Sopenharmony_ci
104159b3361Sopenharmony_ci
105159b3361Sopenharmony_ci
106159b3361Sopenharmony_ci70. Use mixed blocks.
107159b3361Sopenharmony_ci
108159b3361Sopenharmony_ci
109159b3361Sopenharmony_ci
110159b3361Sopenharmony_ci90. Use intensity stereo. This is a must-have for low bitrates, but if the
111159b3361Sopenharmony_ci    algorythm is very good it could also be used in every case.
112159b3361Sopenharmony_ci    Note: mpg123 (and all derivatives, like xmms and lame/mpglib)
113159b3361Sopenharmony_ci    have bugs in the intensity stereo decoding.  Bugs have been there
114159b3361Sopenharmony_ci    for years since there are very few intensity stereo mp3's out there.
115159b3361Sopenharmony_ci
116159b3361Sopenharmony_ci
117159b3361Sopenharmony_ci
118159b3361Sopenharmony_ci95. Merge GOGO's fast assembler routines.
119159b3361Sopenharmony_ci
120159b3361Sopenharmony_ci
121159b3361Sopenharmony_ci
122159b3361Sopenharmony_ci96. It would be nice to save some information whilst encoding
123159b3361Sopenharmony_ci    a: wave -> mp3
124159b3361Sopenharmony_ci        a RIFF/wave can contain LIST chunks with information
125159b3361Sopenharmony_ci        about author, title, etc. 
126159b3361Sopenharmony_ci        ==> could go into TAG fields of resulting mp3
127159b3361Sopenharmony_ci    b: mp3 -> mp3
128159b3361Sopenharmony_ci        ==> we could copy the TAG directly
129159b3361Sopenharmony_ci    c: mp3 -> wave
130159b3361Sopenharmony_ci        ==> copy TAG into LIST chunk
131159b3361Sopenharmony_ci
132159b3361Sopenharmony_ci
133159b3361Sopenharmony_ci
134159b3361Sopenharmony_ci97. Integrate plusV extensions
135159b3361Sopenharmony_ci
136159b3361Sopenharmony_ci
137159b3361Sopenharmony_ci
138159b3361Sopenharmony_ci99. To be able to encode as fast as FastEnc
139