I am aware of these rather formal aspects. With the criteria of a
self-describing format fulfilled, it comes down to a naming convention.
Why that is part of a format specification is unclear to me.
Moreover it may cause what is actually a misconception according to the
below standing criteria that opening the container according to the .amb
extension is a requirement. It should be rather an option (to those who
would like to have a proprietary extension), and the requirement is to
handle the stream correctly within a file with a standard .wav extension.
Unless there are practical aspects, like the custom GUID would crash
most of the amb-agnostic players, which I doubt. Even then, the motive
should be given in the specification. Sheep should be called sheep. All IMO.
Sebastian Gabler
Am 02.10.2013 12:52, schrieb Richard Dobson:
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
[email protected]
https://mail.music.vt.edu/mailman/listinfo/sursound
_______________________________________________
Sursound mailing list
[email protected]
https://mail.music.vt.edu/mailman/listinfo/sursound
