After doing a lot of automated seek testing on files, it looks like the length of the sync code (currently 9 bits) is not long enough to enable a really robust AND efficient seek algorithm. Lengthening the sync code will require a format change (i.e. FLAC <0.8 streams won't play back on FLAC >0.9 decoders), so I'm sending this message out to see if there is any "NO DON'T DO IT!" kind of feedback from users. While I'm at it I will probably add a frame-level CRC as a frame footer which will help decoders reject corrupted frames. Josh __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
> JC> After doing a lot of automated seek testing on files, it looks like > JC> the length of the sync code (currently 9 bits) is not long enough to > JC> enable a really robust AND efficient seek algorithm. Lengthening the > JC> sync code will require a format change (i.e. FLAC <0.8 streams won't > JC> play back on FLAC >>0.9 decoders), so I'm sending this message out to > JC> see if there is any "NO DON'T DO IT!" kind of feedback from users. > > i think you should change format 'cause everyone was warned about > possible format change and noone uses flac for archiving now. > while it's beta we should just test and improve format. > it'll be harder to do later and tail of compability patches > can make format too complicated. > ~~~~~~ > andreiI also think you should change the format now, and I *do* use FLAC for archiving. When I write FLAC files to tape, I also write the FLAC program(s) I used for the archive. Before removing the original, I verify that uncompressing the FLAC file gives me back the original. It's much better to change the format now than after 1.0. FLAC files from 0.4, 0.5, and 0.6 can't be uncompressed with the same program, so there's no reason to expect 0.8 and 0.9 or 0.9 and 1.0 to be compatible. However, all 1.x versions should have a compatible format. Now is the time. Larry Fenske
--- Andrey Astafiev <andrei@tvcell.ru> wrote:> JC> While I'm at it I will probably add a frame-level CRC as a frame > JC> footer which will help decoders reject corrupted frames. > > idea: maybe you'd add a key to encoder that will add stub for > id3v2 tag of specified size (just like for PADDING block). >Yeah, that's on my list of TODOs. Since it's not really format related it might not make 1.0 but it would be soon after. Josh __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
JC> After doing a lot of automated seek testing on files, it looks like JC> the length of the sync code (currently 9 bits) is not long enough to JC> enable a really robust AND efficient seek algorithm. Lengthening the JC> sync code will require a format change (i.e. FLAC <0.8 streams won't JC> play back on FLAC >>0.9 decoders), so I'm sending this message out to JC> see if there is any "NO DON'T DO IT!" kind of feedback from users. i think you should change format 'cause everyone was warned about possible format change and noone uses flac for archiving now. while it's beta we should just test and improve format. it'll be harder to do later and tail of compability patches can make format too complicated. JC> While I'm at it I will probably add a frame-level CRC as a frame JC> footer which will help decoders reject corrupted frames. idea: maybe you'd add a key to encoder that will add stub for id3v2 tag of specified size (just like for PADDING block). ~~~~~~ andrei ICQ: 111725051