> > Does
> > "0x0001 - Frames field is valid"
> > actually mean
> > "0x0001 - Frames field is PRESENT"
> > ?
>Yes it does mean that.
Right! _Now_ that makes sense! Thanks.
> > If so, then a full-and-working header will be 120bytes long.
> > So as long as we pick a frame which will always contain >= 120
> > useable bytes then the audio frame which holds the xing header
> > will always be the same length when making rockbox recordings.
> > Better still pick a frame size which will also allow for a
> > full LAME header-extension too.
> >> (2) Even when the xing data structure size is fixed, the
> >> whole
> >> xing header can't be, because the data structure resides
> >> in
> >> an mpeg audio frame. MPEG audio frames can only have
> >> certain
> >> lengths which are different for different MPEG version,
> >> layer and sample frequency.
> > We need to check how big the LAME header may be at maximum and
> > what a suitable audio-frame header would be to ensure the
> > data-space required.
> > I shall leave that bit for someone who is in the position to
> > go ahead from there and make the relevant changes to the
> > rockbox code ...once the LAME header size is known it should
> > be a trivial task.
>Rockbox already does a (simplified) selection of a suitable frame
>The point is that the possible frame sizes depend e.g. on
>the sample frequency, and there is *no* frame size that is valid
>for all sample frequencies. We don't know the recording sample
>frequency beforehand, at least with s/pdif.
I hadn't considered s/pdif, in fact have never actually used it myself (not
IN to my jukebox anyway)
Anyway, I've looked at the LAME header specs further
and the whole standard is clearly an after-thought and quite a
mess. Having looked closer, I think patching the ID3v2 tag length to cover
the botch is a probably the most viable solution! :)
> >> >> This could be properly fixed by adjusting the size info of
> >> >> the id3v2 tag to include this empty space.
> >>> Yes, that is probably the smartest option, as removing
> >> them
> >>> will mean copying the entire file.
> >> Copying the whole file on target while recording is simply
> >> out of question. That's why the headers are handled like they
> >> are handled in the first place. For the same reason, recorded
> >> files do not include a toc in the xing header - it would mean
> >> to scan the whole file. You can do that manually with the
> >> vbrfix plugin, then you will get an idea how long it can
> >> take...
> > I appreciate that xing header cannot be created during
> > recording. But patching the front of the MP3 file so that the
> > recording is "valid" would be simple.
>Yes. It requires some understanding of the id3v2 standard
>though, so I wouldn't call it trivial. Should be fairly easy
the first three bytes of the 10 byte header are "ID3"
the tag length is held in bytes 7, 8, 9 and 10
only 7bits of each byte are used,
so a maximum length of (2^(32-4))-1 is possible
hdr =(len>> 7)&0x7F
hdr =(len )&0x7F
else "length too big"
lmk if you need any other id3v2 info
> >> The goal for rockbox is of course to avoid the necessity to
> >> fix the recording files. To achieve this, it is necessary to
> >> frame-walk while recording. This would also enable it to
> >> always know the exact frame count (today we need to estimate
> >> for recordings where the MAS internal 20-bit frame counter
> >> saturates), and always reliably split at frame boundaries.
> >> One day I'll implement this...
> > LOL ;)
>That's was absolutely serious. I'll do that before the next
>release, I promise.
I know you're serious - I was laughing at how the "one day" made it clear
that your todo list was quite impressive before adding this non-trivial task.
Received on Mon Nov 7 03:26:18 2005