> 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
size.
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
http://gabriel.mp3-tech.org/mp3infotag.html
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
though.
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
eg
if (len<=0x0FFFFFFF)
{
hdr[6] =(len>>21)&0x7F
hdr[7] =(len>>14)&0x7F
hdr[8] =(len>> 7)&0x7F
hdr[9] =(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.
BC
Regards, Jens
