Hello David,
Monday, May 22, 2000, 9:50:14 AM, you wrote:
DB> How about prepending some "dummy" data to the input ( zero value samples
DB> ), note its length and then encode it together with the normal input.
DB> When decoding , just discard the noted length of samples ( + plus the
DB> ones added by the decoder delay ) from the decoded data and start
DB> playing
DB> at the "right" spot ?
DB> Because you are not cutting mp3 data , but normal samples , there should
DB> be no added distortions. I think ... :-)
This is what I initially suggested. That would somewhat work with a full album (1 big
wav), but if you rip
track by track you have problems with the first/last frame: it
fades in/out.
The reason this happens is because the data before/after are _already_ 0's.
It would make no sense to add more 0's because you would still get
that fade. Adding more 0's would only delay the problem.
Segher Boessen says you can clearly hear this when the two
things are concatenated back together later and played as 1 whole.
The you could try feeding some other data so that the fade is gone (I
suggested 3 ways), but if this should work, and you later concatenate
to 1 big mp3/wav you again get distortion at the border.
----[clear moment]----
It _should_ be possible to encapsulate the actual data from the prior
frame(s?) in some extra frame, so that a normal player doesn't play
this (silence), and a compliant player can correctly init the 50%
overlap. [works everywhere, but start of 1st track and end of last]
----[/clear moment]----
But then you would also need an "aware" concat, so that you first remove the
extra frames and then only concat the original material.
Then the whole issue would be to get players compliant, so that, for
example, they do not re-init DSP (click, pause) inbetween every track,
To be honest imho, players could have already been working if used
musicutter mp3's (cut on a frame-basis), and just re-concatted on the
fly. They don't.
This solution would work, but you'd need a very un-natural
(almost perverse) manipulation of the mp3 standard in every single
track. I think it would be almost impossible to defend such a
standard.
So for me now, a new (set of) TOC frame(s) (so there is enough room)
( http://www.mail-archive.com/mp3encoder%40geek.rcc.se/msg02829.html )makes
most sense, because it would clearly give that mp3 the identity
"I am a complete album", and a player would be able to recognise/decode
this perfectly in an unequivocal fashion.
If you'd still prefer separate mp3 tracks, you can always use, for
example, musicutter on the large mp3 later on.
DB> - remove samples from the end of decoded.raw , until
DB> length_of(decoded.raw) == length_of(music.raw)
this is happening to great extent already in the new "--decode"
function of Mark Taylor.
--
Best regards,
Roel mailto:[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
