|
Rockbox mail archiveSubject: Re: Bad Recorded MP3s - may not be (solely) a DAC issueRe: Bad Recorded MP3s - may not be (solely) a DAC issue
From: Jens Arnold <arnold-j_at_t-online.de>
Date: Mon, 07 Nov 2005 02:09:12 +0100 On 06.11.2005, Bluechip wrote: >>> >> http://www.codeproject.com/audio/MPEGAudioInfo.asp#Anchor-4.-34080 >>> (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 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. >> >> 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 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 |