Re: How important is being syncable?
Reply #1 – 2023-01-16 20:19:10
I don't know a lot about streaming, but I have looked at Icecast. It serves a separate stream to each client, first serving the necessary headers. This means most software wouldn't even see a difference between a file and a stream other than not being able to seek. I'm unsure whether this is how internet radio works in general? The obvious use case is picking up in the middle of an actual stream where for whatever reason there is no onboarding process. Does streaming even use this property of an audio bitstream or do they use the syncable trait of a container, or not rely on syncable at all? The way FLAC is designed forces you to do so, there is no other way to seek except for having a seektable pointing to every single frame. Other codecs, like for example WavPack, store a frame length making it possible to quickly skip a frame, but I wouldn't be surprised when players only do this for the last few seeking steps. A file player could use it to seek, but do file players do this? To me it seems better to use a combination of a seek table and filling in gaps in the seek table as useful intermediate seek points are encountered for better resolution Just having a sync code is enough for this and seeking, there is no need for a complete context (sample rate, bit depth, number of channels) like FLAC does. Corrupt frames can be skipped by fumbling until synced, minimising the damage of a corruption. This doesn't necessarily need "syncable" to do, but it is required to do it efficiently Using flac just as an example that's well known and because poking around flac prompted the question, flac adds about 3KB per minute of normal audio (CDDA, fixed blocking strategy with normal-sized blocks) to allow the bitstream to be syncable. Flac's implementation of syncable goes to lengths to make it performant so a different codec might add even less. This isn't much for a lossless codec so in practical terms the question isn't hugely relevant, but theoretically it's still interesting IMO.All of this is really unnecessary in streaming as we see it these days. It would have been useful if multicast streaming would have picked up, but it didn't. The way flac is designed to be syncable basically adds or ensures 0's exist in the bitstream wherever possible (so that encountering what looks like a sync code is likely to actually be a sync code, for performance). It also repeats information necessary to decode in the header of every frame. The entire design of the bitstream is to allow syncable to exist so it must have been important at the time, but is it just a legacy feature that is rarely actually used?So, the TL;DR here is: the sync code is (by design) useful in seeking and for handling of corruption. The rest of the frame header isn't, because multicasting never took off. There is one marginally relevant format of which I'm sure decoding cannot be picked up in the middle of the stream for certain streams: MPEG-4 ALS. On encoding, it is possible to select an option that makes 'seeking' impossible, by having each frame depend on the frame before it.