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