Hello mr Mark Taylor,
MT> This would work, in the sense that it would allow a
MT> a fully mp3-lapse-aware decoder could then be made so that
MT> % lame input.wav - | lame --decode - output.wav
MT> would have sizeof(input.wav)==sizeof(output.wav).
:)
MT> As a first pass, I just modified "lame --decode" to remove
MT> exactly 1104 samples (572 sample delay from LAME encoder,
MT> 528 from LAME/mpglib decoder). But other decoders have
MT> different delays. (ISO based: 528. FhG: 1160 +/- a few
MT> samples depending on quality setting).
great, progress in the right direction :)
MT> There are still a couple of problems: the first and last 96
MT> samples will be attenuated by the MDCT window (multiplied
MT> by a function which goes from 0 up to 1) so the volume will
MT> go to 0 at the start and end. (= clicks if you concatenate
MT> the .wav files together).
Would it help to add 96 0-samples in front and at the back of the
stream? A non-compliant player would just add a few ms of "nothing",
while a compliant decoder would nicely truncate by 2*96 (or just the
absolute intro and trailing silence because no more __.oOSS... and
...SSOo__. but
just __SS... and ...SS__ (cut '_')?
MT> There are other problems for perfectly seemless concatenation,
MT> caused be the fact that mp3 frames overlap by 50%.
MT> so to encode frame N, you need 50% of the data from frame N+1
MT> (and to encode frame N+1 you need the last 50% of the data from
MT> frame N).
This is a shortcoming, and since it's not up to the lame module to
"find out" what the last frame of the previous and first frame of the
next mp3 will look like, it's an acceptable risc.
I don't know what happens to a normal mpeg stream with the first and
last frame anyways, but don't you always get this at start and end?
btw: would that 96 0-sample interfere with this overlapping thing?
MT> One thing that would make these problems easier to solve would be to
MT> write a 0 delay encoder and decoder.
Is this a theorethical possibility within mp3? If you cannot represent
a discontinual signal with cos's (only in limit), won't you always
have some inertia in dynamics (thus need to start out/stop with some sort
of lead-in/out)?
MT> When Takehiro rewrote the
MT> filterbank/MDCT in LAME, he reduced the delay from 528 to 48, and I
MT> think this could be reduced to 0? Then put the same technology into
MT> mpglib. Problem is, this is a lot of technical coding, for a very
MT> limited application. I've suggested it several times, and no one has
MT> ever volunteered :-)
As a non-code-contributor, I can only say me and a LOT of people are
very thankfull for the effords and work put into LAME. Since I set up
the r3mix.net site, I get a _lot_ of thank you notes, and all this
because there is a thing such as "LAME".
If possible, it sounds like a real challenge, but I don't agree with
that "very limited application".
At the moment the only way to rip a live performance is, indeed as
mentioned, to do it in 1 big mp3, and then later manually edit the
frames and split up the thing.
The reason not many people ask for such a function, is just simply
because they don't know their live albums are ripped non-perfectly.
MT> And, here's something I post ever few weeks or so:
thanks, I'm reading and learning :)
--
Best regards,
vdbj mailto:[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
