Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: YALAC - File format development (Read 15175 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

YALAC - File format development

Reply #26
I suspect streaming support will become more important in the years to come, as IPv6 becomes the standard and multicast becomes possible and popular. Streaming lossless really will be a viable option and probably quite common at that.

That said, my audio collection is half a terabyte strong, and my priorities are towards getting the most out of my hard drives. Any options that save me disk space, however minimal, are options I would use...

My favorite idea proposed so far was the idea of leaving the streaming data out and letting streamers add it on the fly.

Good luck with your endeavors.

YALAC - File format development

Reply #27
File format finalized

(Only some minor modifications may be applied if neccessary)

TAK (formerly known as Yalac) will use it's own proprietary (spelling?) container format. It has been designed for:

- simplicity of use (for other developers)
- small storage overhead (only about 0.07 percent worse compression with the default settings)
- configurability for specific playback requirements.

Not a big thing but it needed some concentration to work out the details.

Because container data and encoded audio data are clearly seperated, it should be easy to wrap the compressed audio frames into other standard containers.

  Thomas

edit: corrected spelling of "proprietary'. Thanks to ShadeST!

YALAC - File format development

Reply #28
How many channels are enough?

(...for the near future)

Although the first public release of TAK will not have multi channel support, the file format allready has been prepared for it.

Because of some internal limitations of the current specification, not more than 16 (possibly 18) channels can be stored. Is this enough?

Higher channel counts would need a modification of the file format, and the compression ratio for the common audio formats would be worse.

I myself see no need (and no chance) to prepare the file format for any possible requirements of the future. You can try this, but it's quite probable, that nevertheless something unpredictable will happen, which anyhow makes a change of the file format neccessary.

 

YALAC - File format development

Reply #29
I don't see myself needing more than 8 channels anytime soon.