Mark Powell schrieb am Sam, 30 Sep 2000:
> On Sat, 30 Sep 2000, Robert Hegemann wrote:
> > > One complication: a vbr tag and id3v2 tag! If there is also a id3v2
> > > tag, it will be written into the bitstream first, so
> > > lame_finish_vbrtag() will have to return a file offset
> > > where the vbr tag starts.
> >
> > How will the library know there is a id3v2 tag, and
> > why should the library know that?
> >
> > I think the mp3 encoding library should do what it is
> > supposed to do, encode pcm samples into mp3 frames.
> >
> > What the client software will add - ID3v2, WAV header, Xing header -
> > that should be of no interest for the *encoding library*.
>
> However, the information in the Xing frame is dependant on information in
> the total mp3 output. Now the encoding library could provide this info
> easily. Why should the client have to calculate this again?
>
> > Sure, we could build a tag library:
> > - routines to add ID3v2 tags
> > - routines to add WAV headers
> > - routines to add Xing VBR headers
> >
> > This library could be of interest for some other clients too, but
> > in my opinion we should not mess it with LAME's encoding library.
>
> This is true to some extent. I think the nature of mp3 files causes
> problems with this. The ideal is to seperate related procedures into
> modules. However, mp3 files combine all this info into one file.
>
> [ ID3v2 ] + [ Xing ] + mp3 + [ ID3v1 ]
>
> Although more elegant from a modularisation perspective to seperate
> functions. It makes the writing of a client more complicated. We're trying
> to make that easy right? The ideal is to modularise the LAME librar(y|ies)
> completely and to let the client write four files .id3v2, .vbr, .mp3,
> .id3v1. However, we have no choice. It's just .mp3 unfortunately. I think
> wwe have to accept the loss of elegance and combine these functions. Moving
> Xing out of encoding library causes complications for the client, due to
> recalculation of the seek table. Moving ID3v2 out of the encoding library
> causes complications for the client, due to file copying.
> Just my tuppence.
ID3 will be handled by the client anyway and is not part
of the encoding engine, as it is completely independent
from MP3. You can also tag .ogg files or .wav files.
The client has to do file handling and will do so
So how will that work?
client writes <ID3v2>
client writes dummy <VBR header>
client asks the encoding engine <-------------------+
to encode a chunk to pcm samples |
and gets back some mp3 frames |
then client writes <MP3 frames> |
---------+
client adds <ID3v1>
client updates <VBR header>
The only thing the client has to do is keep track of the number
of encoded frames. I don't see a problem here.
Ciao Robert
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
