|
22289
by wiso
copy lame-3.98.4 to trunk |
1 |
1. bug in resample code: downsampling from 44101 to 44100 causes |
2 |
a seg fault. Workaround in place for now: resampling disabled |
|
3 |
if input/output samplerates agree to 4 digits. |
|
4 |
||
5 |
||
6 |
||
7 |
2. high bitrate encodings have trouble on some hardware players. |
|
8 |
Track this down. Probably caused by --strictly-enforce-ISO and |
|
9 |
IXMAX_VAL. Try setting IXMAX_VAL back to 8191 and/or |
|
10 |
maxmp3buf=8*960 to see if there is a working combination. |
|
11 |
||
12 |
note: one of the decoder bugs was identified. It is caused by using |
|
13 |
different block sizes on both channels. A parameter need to be |
|
14 |
added to Lame to handle workarounds. |
|
15 |
||
16 |
||
17 |
3 frontend: code is a complete mess. But it has so many debugged |
|
18 |
features it will be a lot of work to re-write. |
|
19 |
||
20 |
||
21 |
4. MSVC project files. It would be nice to create a working |
|
22 |
MSVC6 workspace, which included all the projects as possible |
|
23 |
targets: |
|
24 |
lame.exe |
|
25 |
mp3x.exe (require GTK libs) |
|
26 |
lame_enc.dll |
|
27 |
ACM codec |
|
28 |
directshow codec |
|
29 |
||
30 |
I think the only MSVC5 project that we need to preserve is |
|
31 |
for lame_enc.dll, since Albert Faber (still?) doesn't use VC6? |
|
32 |
But no reason we cant have VC5 and VC6 project files for the dll.
|
|
33 |
||
34 |
|
|
35 |
||
36 |
|
|
37 |
||
38 |
||
39 |
5.
|
|
40 |
NOGAP encoding:
|
|
41 |
||
42 |
-nogap: more testing, fix options, test id3 tags?
|
|
43 |
Can we change id3 tags without reseting the encoder??
|
|
44 |
At the end of encoding 1.wav, call lame_get_mf_samples_to_encode()
|
|
45 |
to find the number of non encoded buffered PCM samples. Then
|
|
46 |
encode samples from 2.wav until these PCM samples have been
|
|
47 |
encoded, *THEN* call lame_encode_flush_nogap() and close
|
|
48 |
out file 1.mp3.
|
|
49 |
||
50 |
||
51 |
NOGAP decoding:
|
|
52 |
lame --decode --nogap file1.mp3 file2.mp3 file3.mp3
|
|
53 |
should also work. What needs to be done:
|
|
54 |
get_audio.c: We need a way to open a second mp3 file, without
|
|
55 |
calling lame_decode_init() and reinitializing mpglib.
|
|
56 |
And the mpglib needs to know to look for new Xing
|
|
57 |
tags at the beginning of file2.mp3 and file3.mp3.
|
|
58 |
||
59 |
||
60 |
||
61 |
6.
|
|
62 |
Does stdin work when LAME is compiled to use libsndfile?
|
|
63 |
(new version of libsndfile will support this - try this out)
|
|
64 |
||
65 |
||
66 |
7.
|
|
67 |
LAME has problems with pure DC input. i.e. a square wave with
|
|
68 |
a frequency well below 20 Hz. Not very important, but it should
|
|
69 |
be fixed.
|
|
70 |
||
71 |
||
72 |
8.
|
|
73 |
mgplib has bugs with i-stereo. flag denoting invalid
|
|
74 |
i-stereo value (= frame is m/s stereo) is not correct.
|
|
75 |
||
76 |
9.
|
|
77 |
lowpass filter: for M/S stereo, use more filtering for the side
|
|
78 |
channel, less filtering for mid channel. We need to first replace
|
|
79 |
the polyphase filter with an FIR lowpass filter with finer frequency
|
|
80 |
resolution before implementing this.
|
|
81 |
||
82 |
10.
|
|
83 |
LAME has a 31 point FIR filter used for resampling, which
|
|
84 |
can also be used as a lowpass. When resampling is done,
|
|
85 |
use that filter to also lowpass instead of the polyphase filter.
|
|
86 |
||
87 |
11.
|
|
88 |
Even when resampling is not needed, should we use an FIR filter
|
|
89 |
for the lowpass? If it is not too much slower, yes. If it
|
|
90 |
is slower, then it should be an option since it will produce
|
|
91 |
higher quality.
|
|
92 |
||
93 |
12.
|
|
94 |
We should consider moving the experts options from the *long
|
|
95 |
help* text into an *experts only* help text. The average Joe gets
|
|
96 |
knocked down by the huge number of possibilities to setup lame.
|
|
97 |
||
98 |
||
99 |
||
100 |
||
101 |
50.
|
|
102 |
Better tonality estimation.
|
|
103 |
Gpsycho uses predictability, and so needs a delay to detect the tonality
|
|
104 |
of a sound.
|
|
105 |
Nspsytune seems to miss tonals when several of them are too narrow.
|
|
106 |
We would probably need the best of both.
|
|
107 |
||
108 |
||
109 |
||
110 |
||
111 |
60.
|
|
112 |
Different ATH handling for sfb21. We are using the minimum value of ath
|
|
113 |
in each whole sfb. in sfb21 this leads to very high bitrates.
|
|
114 |
We could perhaps use 2 or 3 ath partitions in sfb21
|
|
115 |
||
116 |
note: partially done
|
|
117 |
||
118 |
||
119 |
||
120 |
70.
|
|
121 |
Use mixed blocks.
|
|
122 |
||
123 |
||
124 |
||
125 |
||
126 |
90.
|
|
127 |
Use intensity stereo. This is a must-have for low bitrates, but if the
|
|
128 |
algorythm is very good it could also be used in every case.
|
|
129 |
Note: mpg123 (and all derivatives, like xmms and lame/mpglib)
|
|
130 |
have bugs in the intensity stereo decoding. Bugs have been there
|
|
131 |
for years since there are very few intensity stereo mp3's out there. |
|
132 |
||
133 |
||
134 |
||
135 |
||
136 |
||
137 |
998. |
|
138 |
Merge GOGO's fast assembler routines. |
|
139 |
||
140 |
||
141 |
||
142 |
||
143 |
999. |
|
144 |
It would be nice to save some information whilst encoding |
|
145 |
a: wave -> mp3 |
|
146 |
a RIFF/wave can contain LIST chunks with information |
|
147 |
about author, title, etc. |
|
148 |
==> could go into TAG fields of resulting mp3 |
|
149 |
b: mp3 -> mp3 |
|
150 |
==> we could copy the TAG directly |
|
151 |
c: mp3 -> wave |
|
152 |
==> copy TAG into LIST chunk |
|
153 |
||
154 |
||
155 |
||
156 |
1500. |
|
157 |
Integrate plusV extensions |
|
158 |
||
159 |
||
160 |
||
161 |
2000. |
|
162 |
To be able to encode as fast as FastEnc |