dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: Bad Recorded MP3s - may not be (solely) a DAC issue

Re: Bad Recorded MP3s - may not be (solely) a DAC issue

From: Jens Arnold <>
Date: Mon, 07 Nov 2005 02:09:12 +0100

On 06.11.2005, Bluechip wrote:

>>> (and others) seem to suggest that the header is always the
>>> same length - can you point me in the right direction for
>> the
>>> information you have please?

>> (1) This exact source tells you that the xing header data
>> structure is *not* alwas the same size - it depends on
>> which
>> fields are present. The TOC makes the largest
>> difference.
>> Of course the maximum size is fixed.

> I've read and read and read that page - and finally I think I
> may see the confusion.

> Does
> "0x0001 - Frames field is valid"
> actually mean
> "0x0001 - Frames field is PRESENT"
> ?

Yes it does mean that.

> 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.

>> >> 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 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.

Regards, Jens
Received on 2005-11-07

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy