> 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.
50% of short type is 192 samples
50% of stop type is 576 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.
It's not the fade that is the problem, it's the mdct aliasing.
>
> 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
The decoder does a 'fade' as well (mdct window).
> 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
If you have track overlap, you can solve it in the decoder. You will
need to modify the decoder anyway, 'cause almost all decoders reinit
the dsp while switching to another track. Sorry...
> 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.
Guess again. Sorry.
>
> 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.
They reopen the dsp as well. Lots of noise.
>
> >> 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.
Aliasing influence is about -6dB, and does _not_ sound good.
Very simply put: if you cut mp3 at the beginning, you're doomed.
Ciao,
Segher
>
> 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/ )
>
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
