Question 1: What is needed for streaming?

ratio SI:A = 1:1   SI A SI A SI A SI A SI ...
-lowest streaming delay
-biggest storage overhead
-purpose: broadcast (streaming)

ratio SI:A = 1:5   SI A A A A A SI A A A A A SI ...
-higher streaming delay
-smaller storage overhead
-purpose: local storage for playback (quick seeking)

ratio SI:A = 1:n   SI A A A A A A A A A A ...
-no streaming support
-no storage overhead
-purpose: archiving (slow seeking)

In my opinion, a file format that supports streaming must allow the decoder to start decoding at an arbitrary position within the stream. That means that all info about the stream that the decoder needs to know must be repeated in the stream.

A generic solution would be to interleave stream info and audio data at an arbitrary, user-definable ratio, for example:
...
The stream info frames could contain info like this: (just an incomplete example!)
- sync code
- SI frame CRC
- audio stream info (sample bit width, sampling frequency, etc.)
- current position within stream (timestamp and/or sample number)
- meta data (artist, title, etc.)

The sync code together with the SI frame CRC lowers the chance for a false positive match to practically zero.

A seek table and other non-streaming info (cue-sheets, album cover JPGs, etc.) could be included in an additional info frame at the start of the file, only. The seek table would allow players to skip as many SI frames as possible (defined by the precision/number of entries in the seek table) to reach the target position within the stream. This quick seeking feature would rely on the presence of SI frames because only those have sync codes that allow the decoder to re-sync with the audio stream. On the other hand, files without any SI frames (purpose: archiving) would require the player to do slow seeking, i.e. to decode the entire audio stream up to the target position.

Code: [Select]

ratio SI:A = 1:n   SI A A A A A A A A A A ...
-no streaming support
-no storage overhead
-purpose: archiving (slow seeking)

' date='Jun 30 2006, 03:45' post='407523']
1)I think it's important to store the complete stream info (sampling rate, channels) in each frame : if a client connects to a stream while it is being distributed, it needs to know how to decode it.  Unless you can detect the frame type from the frame itself without explicitly specifying the data, you'll need to include it.

' date='Jun 30 2006, 03:45' post='407523']
Thanks for all your hard work,

decide to implement SI frames, it would be nice to drop sync codes in usual frames... And, may be, it will be possible to add SI frames "on the fly" - when streaming.

Have you considered one of the existing container formats for your codec?

Using one of them would mean that you wouldn't have to re-invent the wheel. 

Best choice would be to integrate YALAC into FLAC.

I think that integrate YALAC into FLAC is a bad idea because:
a) FLAC files created with YALAC will be incompatible with existing FLAC decoders. Most people will avoid use the new method because they don't want to have compatibility problems.
An analogy is the ZIP format: BZIP2 is a part of the zip standard but nobody use it because only a few programs can decompress it.

b) All players and hardware that want to support the FLAC format must be able to decode the FLAC algorithm and the YALAC algorithm. That doesn't help FLAC to gain support.

As for specifying the stream info, could YALAC have a standard where if it is the most common type (i.e. Stereo 16 bit 44,100 KHz), it's optional, but make it mandatory to modify this... i.e. mono 16 bit 44,100 khz has to specify that it is mono, because this is the only thing that differs from default... you only need to add the symbol for mono into each frame header, but not all the other details.

That's an interesting idea that smack has about being able to customize the streaming info ratio... if you intend to stream it, you can optimize it for this purpose.  Of course, odds are that a user will eventually want to stream files, but this wasn't a concern when the files were first created.

Seems to me that the stream robustness info (sync codes, checksums) should be part of the stream. Metadata (sampling rate, bits per sample, channels) should be provided by the container. Container blocks do not have to match frame boundaries.

I think that Yalac should be designed in such fashion that the container can be replaced with a different one if desired. And if you have a copy of the file header, you can decode the stream starting at any point.

In my opinion support for seeking should be kept in the container, but there is probably a case for including it in the stream instead.

...And, what's important, it is already developed and supported by various software applications, which won't be the case with all-new format.

Quote from: jido on 2006-07-03 17:22:46

Seems to me that the stream robustness info (sync codes, checksums) should be part of the stream. Metadata (sampling rate, bits per sample, channels) should be provided by the container. Container blocks do not have to match frame boundaries.

I think it's the other way around: framing and synchronization is provided by the container format while all audio related info is stored in the embedded audio stream.

The container format is handled by a software component "parser/splitter" which extracts the payload stream (here: audio) and sends it to the decoder. The decoder can only handle such a raw audio stream, it doesn't need to know anything about sync codes, checksums or error correction codes.