Brian Willoughby
2011-Mar-06 05:45 UTC
[Flac-dev] FLAC__stream_decoder_skip_single_frame() // how is it used?
Hello all, I would like to copy a FLAC file without decoding and then being forced to re-encode. All I really need to do is run the bare minimum of the decoder to find FLAC frames and then I should be able to write the frames unchanged to the destination file (*). libFLAC offers the FLAC__stream_decoder_skip_single_frame() function to provide half of this, but I cannot figure out how to (officially) obtain the encoded FLAC frame. When performing a full decode, the write callback makes each frame visible to the application, but that's only after it has been decoded, which takes extra CPU time. What I think I need is a 'skip' callback that just gives the frame header and pointers to the encoded data. Does anyone have any hints? I'm still looking at the flac command- line sources, and also digging into the libFLAC sources to see how things work, but I haven't found an obvious solution. The documentation seems to suggest that there are valid reasons to scan without decoding, but the only thing that seems possible is to check for errors and compute the MD5 sum. I'd actually like to go further than those examples and access the encoded data. I have a feeling that my question has been asked before, or at least a similar topic, but searching my archives back to 2006 doesn't reveal anything. * One potential issue is that the FLAC frame may not be byte-aligned, such that perhaps the encoded data can't simply be copied to a new, shorter file without shifting bits around. Then again, perhaps the FLAC header is byte-aligned at the start, and only the encoded contents are bit-aligned. I'm sure this particular question is answered in the documentation of the file format, but I wanted to mention it in case it affects my situation. I'm certainly planning to read the format and API documentation thoroughly. Brian Willoughby Sound Consulting P.S. My desired application is to take so-called 'hidden' tracks from a CD and split them into two files by dropping the silence in between. It's fairly common to have an 'extra' track on a CD that is only slightly hidden, where several minutes of silence are inserted after the last listed track, followed by the 'hidden' track. I just purchased several lossless music titles online, and a few have these hidden tracks. Of course, I'll preserve the original files in my backup, but it would be handy for listening if I could just dump the silent sections and keep two shorter tracks - this sure would save dead air on my music player. My idea was that since FLAC already encodes silence in a special way (independent, constant.value = 0), then it would be far faster and simpler to detect the middle stretch of silence by dealing directly with the FLAC-encoded files. I'm not worried about keeping 1 or 2 seconds of silence at either end, as would happen when copying whole FLAC frames, but really just want to discard most of the long silent sections so I don't have to listen to them. I have code running which can detect the silent sections reliably, but only when fully decoding.
Seemingly Similar Threads
- Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
- Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
- OggFLAC streaming is systemically broken.
- Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
- Synchronizing a streaming client to the server Was: Idea to possibly improve flac?