Hello,
I'm no ingenieer, and (F)FT and DCT are not things I'm very well
aquainted with, so I'll try to explain with the tools I have:
Real-Life Problem: I don't succeed to back up live/mix albums with any
encoder. I rip seperate wavs and encode-decode them seperately. After
manually removing all Info headers and Tags on them damn mp3's, and
"--decode"ing with same tool as encoding, result still lacks.
practically: LAME -V1 -mj -b128 -h -t gives me �8 ms at the end of
track N and �20 ms at the start of track N+1, resulting in a 30 ms
"silence" when concatenated.
Technical problem: From what I mean to understand about mp3, the
last frame always has some padding due to a restriced set of discrete
frame lengths.
Why there is a silence at the start of the first frame I don't know,
but I invented some pre-echo reserve or something to make it
understandable for myself. (perception eh ;))
What I suggest to compensate for this 'mp3 lapse':
1- (preferable): first encode the stream, then insert precise
start- and end-point into Info header (like extension to Xing VBR
one). Then a tool aquainted with this extended header would be able
to do a very accurate "--decode" (hint :)), and a later concatenation
would be within margin of perfection.
I took the liberty to quickly (don't know C) browse through the lame
source, and I saw a larger frame size was taken compared to Xing for
info header, so LAME string could be included. Maybe some (extra) room
could be utilized to store those extra few start- and stop bits?
If possible (don't know about feasibility) a nice math formula to
determine exact (up to, for example, ms) start and end of the encoding
stream. ((*)maybe exact location of END would do it, because
exact_END-pcm_length=exact_start)
If not maybe that nice analog silence detection (up to 22kHz :)) to determine where
sound starts (and/or)(*) stops. [problem if cd had normal silence in
orig pcm: maybe only analyse first/last frame? If complete frame =
analog silence then (start/stop)=0 ms from (begin/end)?]
btw: if this idea, or some variant, is realised, you might want to
give that info-header-extension a name, so that compliant
decoders/players can be recognised.
2- (not so handy from user perspective), when encoding 1 big wav, eg.
EAC can extract whole cd as 1 wav + make "cue" sheets:
PERFORMER "Orbital"
TITLE "In Sides"
FILE "E:\mp3\Orbital - In Sides\Orbital - In Sides.wav" WAVE
TRACK 01 AUDIO
TITLE "The Girl With The Sun In Her Head"
PERFORMER "Orbital"
INDEX 01 00:00:00
TRACK 02 AUDIO
TITLE "P.E.T.R.O.L."
PERFORMER "Orbital"
INDEX 00 10:26:65
INDEX 01 10:26:67
....
TRACK 08 AUDIO
TITLE "Out There Somewhere? (part 2)"
PERFORMER "Orbital"
INDEX 01 58:35:72
Problem here (with all encoders that I know) is that (wintel) after the
orig_WAV->MP3->decoded_wav conversion, orig_wav and decoded_wav never
have the exact same size. Nothing too bad here, but the start points from
tracks on the new cd burned from CUE+decoded wav will differ a slight
bit.
Maybe a solution could be found so that:
size([lame --decode]([lame -V1](orig.wav))) = size (orig.wav)?
Just some ideas, and I'm possibly the 6 billionth person to bring
those forward here, but since I don't see a solution with current
tools I thought I'd mention them...
[thanks for your attention and reading all the way down here :)]
--
Best regards,
vdbj mailto:[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
