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
