Re: [Sursound] Patent application: Data structure for HOA [RANT]
On 28/10/2012 23:12, etienne deleflie wrote: Hi Richard, .. 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). The users who have been emailing me are all working at 24/96. I think the conclusion must be that nobody working in surround has any reason at all to be targetting CD, in which case they have no reason at all to use 44.1KHz. That is no longer the relevant basis on which to evaluate a soundfile format. .. 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. The trouble is that in a sense UA isn't a file format at all, in the meaning of something defined formally and rigorously. It is a described procedure. It relies on the (external) definition of WAVE, plus the (private) definition of a wv file. In the end, any binary file format has to be defined literally byte by byte in terms of the type and meaning of each distinct field; 4 bytes for a magic name, 2 bytes for a bitfield, 4 bytes for size in sample or frames or whatever. And then there are further rules about higher levels of organisation: chunked? Order of frames in each chunk? variable-size chunks? chunks in any order, or in strict strict sequence? Available range of chunks? User-defined chunks? Endianness? Multiple instances of chunks? And so on. In the end the issue resolves to whether that byte by byte spec is fully public or not. If not, it is a private or proprietary format, which only authorised applications may read and write; e.g. by the developer signing an NDA with the company owning the format and maybe being required to use their API to deal with it. The WAVE format is still as valid now as it was when it was defined however many decade ago that was. In that sense it was already future-proof, except insofar as needs have changed and the initially fantastical 4GB limit is now no longer sufficient; in much the same way that a computer with 64K of RAM is no longer sufficient. In effect, the only aspect that disambiguates UA from any other wavpack-wrapped file is the text name required to be added to the wv header. By contrast, in a way the rules dealing with encoding coefficients etc are just a local detail. ... 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? ?? they do, behind the scenes. In the case of the iDevices, apps can be declared by the programmers to support "shared files" which are visible via iTunes; and any app can arrange to at least export files via the net. This is how all those music synth apps etc enable users to transfer files from their iPad to the host machine. Each app sits in its own sandbox, and can see only its own files. Of course the user interface does not provides anything recognisable as a system-wide file manager - apps do have a concept of files, but that is mostly (but not 100%) hidden from the user. 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. I am not aware that any mobile devices support more than stereo output with native hardware; but you could always send Apple or whoever a feature request. But you do make my point, that the details of a file format are in the end relevant to application developers; the more transparent (and simple) the process is to the user the better! Richard Dobson ___ Sursound mailing list Sursound@music.vt.edu https://mail.music.vt.edu/mailman/listinfo/sursound
Re: [Sursound] Patent application: Data structure for HOA [RANT]
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 Sursound@music.vt.edu https://mail.music.vt.edu/mailman/listinfo/sursound
