Hello Segher,
Friday, May 19, 2000, 10:48:54 AM, you wrote:
>> After reading that extensive explanation that you posted a few weeks
>> ago, I'm under the impression that 96 0-samples won't change a thing
SB> Actually, 576 samples.
50% of granule of "SHORT_TYPE" or "STOP_TYPE" is 96 samples.
>> because these are the cause of the 0->1 factor up to 50% of the first
>> frame. Apologies for assuming the fix would be easy.
SB> Sorry, it's impossible even.
It's hard to believe there is no way to (*)remove that "fade-in" or
"fade-out" effect by:
- feeding the encoder something for the 0th frame, so that the 1st 50%
of the 1st frame does not "fade"
- feed the encoder a modified first frame that compensates for the
50% fade
- change the code so that frame 1 and last don't use 50% overlap.
I'm not saying it's easy or obvious to implement, but I find it hard to imagine
"impossible".
If you can get rid of the "fades" on the encoder side of the mp3
story, then you can cut samples at the decoder side. Constant at the
start, some padding at the last.
Once you accomplish this, you can build a 1:1 wav-size solution that
can encode a complete cd to 1 wav, and then encode + decode to same
size wav -> usage of cue sheet and "musiCutter" like Caster said.
I am aware that you would need some track-overlap to get "perfect"
results. When working with separate tracks, this is excluded a priori
because you never know what last/following track will be.
I am curious though, how such a set of (*) concatenated
(non-overlapping) mp3 tracks sound on a decoder that trims the
0-samples at start and end. I'm guessing you don't even hear where
the last frame of N and the first of N+1 connect.
With current players it seems impossible to get a good sounding
mp3-playlist made by "musicutter-mp3's", because, as Mark Taylor said,
there is a delay in the decoders anyway.
>> What would be needed at encoding time is some data fed to the
>> encoder so that, for example, at 12.5% of 1st frame the 0*.75+S*.25
>> influence would seem S*.75+S*.25 or 0*.75+(S/.25)*.25. But I have, of
SB> The frames are _not_ just multiplied with the window; there are aliasing
SB> components in there too. And you can't eliminate those.
It was the best compact notation i could come up with to symbolise %
of overlap-influence.
SB> Second problem is, the last frame is padded, because generally, your input
SB> wav is not a multiple of 576 samples long.
Mentioned in initial post.
--
Best regards,
vdbj mailto:[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
