|
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: Bluechip <csbluechip_at_gmail.com>
Date: Mon, 07 Nov 2005 02:25:45 +0000 > > 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 Received on 2005-11-07 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |