Hi,
Below is my first pass at stripping unnecessary or "troublesome" parts from a FLAC encoding. Keep in mind, my goal is an encoding suitable for a transport protocol to define a "virtual wire".
See
for the authoritative definition of the FLAC format, itself (and for details thereof)
I'm not sure if *any* sort of "marker" is needed to indicate the start of a stream. In one sense, the stream has a single start -- which may *precede* a device's IPL! OTOH, there may be a need to signal some significant change in stream characteristics that isn't handled by the mechanisms that follow...
I see no value in (most of) the metadata blocks supported in FLAC (with the possible exception of *parts* of STREAMINFO). Keep in mind the consumer of the stream is an audio device, not a "human user" (with a GUI). So, APPLICATION, PADDING (?), VORBIS_COMMENT, CUESHEET and PICTURE seem to have no bearing on the "sound" being reproduced. The SEEKTABLE might have use -- depending on the sizes of frames and possibly to facilitate prediction of where to "reconnect" to a stream (though the FLAC format only allows the SEEKTABLE to appear at the start of the "file" -- hardly useful for a stream of indefinite length!).
[with that restriction in mind, I suggest the metadata blocks be supported "wherever" in a stream so they can be injected where appropriate/useful]Some retained parts of the STREAMINFO block (esp if it is allowed to be reinserted into the stream as needed) could carry over to reduce or alter the FRAME_HEADER. Or, be eliminated by observing their counterparts *in* the FRAME_HEADER (which *is* present throughout the stream)
I need to look at the blocking strategy implementation in the encoder to see if it can be "fixed". Since FLAC claims it can't change in a "file" (stream), it makes sense to not *support* changes when you consider my streams as having infinite length. I.e., pick a setting and deal with it, always. This eliminates the need to
*verify* that the strategy indication has NOT changed midstream (error).I haven't (yet) sorted out the magic behind the predefined block sizes. Are these values tied to some aspect of "audio signals"? Or, are they just economies that the encoder/decoder can exploit? I.e., why 192 instead of 193? or 128? Since I will constrain the maximum frame/block size (to address hardware limitations in the clients as well as the actual transport mechanism), some of these values might not make sense.
The choices for sample rate seem generous. But, are they geared to simplifying support for other CODECs/containers? I.e., is it better to just resample the source and pick a more limited set of sample rates? (note that this also has consequences for the hardware that is "playing" the samples... 45,196Hz would probably be a Bad Choice for a sample rate -- though the FLAC format allows it to be used!)
Channel assignment brings up the issue of whether or not to treat all sources as mono (i.e., generate two streams for a "stereo" application) or not. Allowing "stereo" encodings can (?) provide some benefit (bandwidth, compression, etc.) but complicates the case when *one* of those channels needs to be routed independant of the other (if that channel happens to be the "side" channel)
Sample size is supported as [4..32] in one place (STREAMINFO) but more limited in the FRAME_HEADER. It might make sense to force it to always be a multiple of 4 (or 8?) and code it in just one place.
The block size and sample rate "overrides" (at the end of the header) might not be necessary if they are ALWAYS encoded in a reduced representation elsewhere.
I don't see any need to change the SUBFRAME definitions -- unless they impose on hardware limitations in the clients.
I'll try to refine this further. And, "fit" it to an actual transport protocol (since bytes in a file are very different from bytes on a wire!). If there's no interest in the actual details, I'll refrain from publishing it, here (you could always find it when I release the sources).