to vdbj: your idea about the info tag for cutting start/end - i just got the
same idea yesterday :))
my opinion is: include the info somehow into the mp3 (maybe extra TAG at the
end of mp3 if it cannot be added somewhere in start) and the included info
would be - number of samples to cut from start, and number of samples to cut
from the end (so these numbers won't exceed some byte-limit if the file is
too big). The decoder would decode the file as normal, but when passing it
to output (soundcard, file) it would cut these samples. lame would use it
on --decode and it could be implemented in some winamp input codec (for
example mpg123...).
However, i have one solution for now - Set the compression in EAC and
determine the encoding offset, then rip the whole CD in EAC with "copy image
and create cuesheet". This will create one big mp3 and a cue sheet. Then use
the program musiCutter from http://macik.homepage.com to split it into mp3
files (it can import the cuesheet so you don't have to manually find starts
and ends of mp3s) Then you can play it with winamp and some continous output
plugin and it plays it really without gaps because musicutter splits between
mp3 frames. When you want to burn audio cd from this, just join these mp3's
together (there's no tool for this yet, you have to cut the possible TAGs
from the files with some TAG program and then join with copy file1 + file2
etc.) Then decode to wav in EAC with the same offset as used for encoding
(so the start of the wav will be without delay and end won't be cut, there
can be added very short silence but it doesn't matter on the last track) and
burn the wav with cuesheet you have. That's how I do it and it's very good
(i don't know better way now).
Caster
----- Original Message -----
From: "Gabriel Bouvigne" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 18, 2000 4:27 PM
Subject: Re: [MP3 ENCODER] bringing down one (more) mp3 restriction [LAME
case projection]
> vdbj wrote:
>
> > Hello Gabriel,
> >
> > Thursday, May 18, 2000, 12:38:53 PM, you wrote:
> >
> > GB> Perhaps we could add an advanced option for adjusting the encoder
delay?.
> > GB> I know that if reduced to the max, it will lower the quality of the
> > GB> first frame, but in some cases it could be a better choice.
> >
> > Wouldn't that be trying to repudiate the inherent nature of mp3?
> > Isn't it quite impossible with those MDCT thingies to represent
impulses? It
> > might work, but at a quality cost. Then also: what about the last
> > padded frame? To me it seems more practical to keep the mp3 stream as
> > it is, but just provide the decoder with exact info on where to begin,
> > and where to end.
> >
>
> The point is that even with an added tag, we can't ensure the delay to
> be reduced in any mp3 decoder, but when reducing the encoder delay, the
> final delay after decoding could be reduced in every mp3 player.
> It's right that it will lower the quality of the first frame, but it's
> very short. I don't remenber the exact of the quality reduction, but
> Mark mentionned it once on this mailing list.
>
> Regards
>
>
> --
>
> Gabriel Bouvigne - France
>
> www.mp3-tech.org
>
> --
> MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
>
>
>
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
