It's not a proprietary extension, any more than is "doc", "txt" or
"cpp". It is simply strongly recommended as standard. It is a common
misconception that a file extension somehow defines a file format. It
does not, and more importantly should not, if the format itself has been
properly designed to be self-describing (this applies particularly to
binary file formats of course). The file extension is a resource to
facilitate exchange, organisation, wild-card selection and filtering,
whether by software or by the user. So much easier to block move or copy
files if you can select based on the extension - amb to this folder, wav
to that folder, and aiff way over there out of harms way.
The other major purpose of a file extension is for OS-supported "file
associations" - double-clicking on a .wav file will open this
application, while double-clicking on a .amb file will open some other
application; both of which you have set up as you want.
So, yes, the application will read the header and discover a file is AMB
(or WAVE, or AIFC) - but how will ~you~ discover its format reliably
just by looking at the extension? If you find a .wav file somewhere on
the net, what do expect it to contain?
Otherwise, you may as well label all soundfiles as .wav (or .tom and
.jerry) , even if they are internally AIFC. It happens!
Richard Dobson
On 02/10/2013 11:29, Sebastian Gabler wrote:
I guess it has been discussed here before, but why again is a
proprietary extension proposed?
See "The use of a custom GUID ensures that AMB files will not (and
should not) be recognised as a soundfile by applications unaware of the
format." Shouldn't that suffice, also for files that have the standard
extension .wav?
(http://dream.cs.bath.ac.uk/researchdev/wave-ex/bformat.html)
Or the other way around: should an application work with the custom
WAVE_EX structure only when the file has the extension .amb?
_______________________________________________
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound
