Hi Richard, > Yes, what it does, it does very well. However, as described, you are asked > to first create an n-channel interleaved WAVE file containing all those > uncompressed silent channels, and pass that to wavpack. Which is fine in > principle, except that with a possibly large number of channels, the 4GB > limit of WAVE will get exhausted very easily. Wavpack ~only~ recognises a > standard WAVE file (i.e it does not make any use of libsndfile etc), it > knows nothing of CAF, w64, etc (to say nothing of AIFF files). I have > already had emails from otherwise happy toolkit users hitting the 4GB limit; > which will of course have to be the next not so incremental update - implies > making a 64bit version of AMB too :-).
The 4GB limit has been considered within UA. The wavpack format itself has the limit of 2^32 samples, which translates to 27 hours at 44 kHz (or 1 hour of 27 channels at 44kHz). In 2009/2010 when I was in discussions with David Bryant (the wavpack author), he said that the next version of wavpack (4.70) would be designed to circumvent the 4GB file limit (either as mono channels or via W64). That version still hasn't come out yet. My understanding is that David is very busy with 'paid' work. So don't use UA right now if you need to use files larger than 4GB (I still havn't hit that limit in my 16 channel 3rd order compositions). But the point is that the 4GB limit is not a function of the UA spec, it is a function of wavpack. So UA remains a future-proof format ... albeit one dependent on another technology. Really, UA is more about fixed channel positions. Perhaps WavPack will never come out in version 4.70 ..... and UA will thus have that problem. Perhaps no one uses UA. Perhaps people stay away from soundOfSpace.com *because* of UA and its channel ordering and limitations. The thing that is really annoying, really frustrating, is that the community that I am trying to serve (which includes me) keeps shooting itself in the foot, incessantly, year after year, by arguing over the same details, over and over and over. It doesn't matter *what* an ambisonic format looks like, as long as there is consensus. Consensus will drive any format far far far beyond its own limitations. That's why I don't really care if UA goes nowhere. Perhaps Furse-Malham AMB should be the default format. Fine. Lets get on with it. I designed UA to try and make people's lives easier, mainly in authoring environments, by having fixed channel positions. If no one uses it then it clearly doesn't make people's lives easier (probably because there are still lots of missing command-line apps required as pointed out). I don't think any patent for a file format that is overly complex will hold any value at all. I wouldn't worry about it. That said, if a commercial enterprise comes up with an ambisonic format that reaches consensus ... I'll be adopting it. (open source constantly fails us, as the surround sound community ... notice that the only browser that CANNOT playback multi-channel audio files in HTML5 is Firefox!). In any case, all inclinations are that file formats are an old-world thing. Notice how Apple's iPad and iPhone and iWhateverelse have no concept of files? Notice how people download apps, as much as they download content? Someone could easily create an album of spatial music, and offer it as an app ... which includes the speaker-feed decoding implemented with whatever channel scheme they wish. You could do that *today*. The file format is irrelevant. Etienne _______________________________________________ Sursound mailing list [email protected] https://mail.music.vt.edu/mailman/listinfo/sursound
