[whatwg] default audio upload format (was Fwd: The Media Capture API Working Draft)

[David Singer]

seems like a comma-separated list is the right way to go, and that audio/* should mean what it says -- any kind of audio (whether that is useful or not remains to be seen).

I would suggest that this is likely to be used for short captures, and that uncompressed (such as a WAV file or AVI with PCM or u-law audio) should be the recommended format.

If your usage is for longer captures or more specific situations, then indicate a suitable codec.

Shouldn't there be statements about channels (mono, stereo, more), sampling rate (8 kHz speech, 16 kHz wideband speech, 44.1 CD-quality, 96 kHz bat-quality) and so on?

On Sep 1, 2010, at 8:21 , James Salsman wrote:

> On Tue, Aug 31, 2010 at 11:24 PM, Roger Hågensen <rescator at emsai.net> wrote:
>>  On 2010-08-31 22:11, James Salsman wrote:
>>> 
>>> Does anyone object to form input type=file
>>> accept="audio/*;capture=microphone" using Speex as a default, as if it
>>> were specified
>>> accept="audio/x-speex;quality=7;bitrate=16000;capture=microphone" or
>>> to allowing the requesting of different speex qualities and bitrates
>>> using those mime type parameters?
>>> 
>>> Speex at quality=7 is a reasonable open source default audio vocoder.
>>> Runner-up alternatives would include audio/ogg, which is a higher
>>> bandwidth format appropriate for multiple speakers or polyphonic
>>> music; audio/mpeg, a popular but encumbered format; audio/wav, a union
>>> of several different sound file formats, some of which are encumbered;
>>> etc.
>> 
>> Actually, wouldn't accept="audio/*;capture=microphone"
>> basically indicate that the server wish to accept anything as audio?
> 
> Yes; that doesn't encourage implementors to implement. However, as it
> was agreed on by two different browser developer representatives, it's
> the best way forward.
> 
>> The proper way however would be to do:
>> accept="audio/flac, audio/wav, audio/ogg, audio/aac,
>> audio/mp3;capture=microphone"
>> indicating all the audio formats the server can handle.
> 
> I agree that the specifications should allow a comma- or
> space-separated list of MIME types. I have no idea why that was
> specifically disallowed in the most recent HTML5 specification, and
> think that decision should be reversed before publication. I also
> think "capture" would work a lot better as an attribute of the input
> type=file element than a MIME type parameter.
> 
>> Although I guess that audio/* could be taken as a sign that the browser
>> should negotiate directly with the server about the preferred format to use.
>> (Is POST HEADER request supported even?)
> 
> Not for multipart/form-encoded input type=file uploads, sadly. There's
> a way to do that specified in http://w3.org/TR/device-upload with the
> "alternates" form POST parameter which the browser would send back to
> the server when the requested type(s) were unavailable. I guess that
> is a content negotiation feature, but it seemed unlikely that people
> would need it for that because ideally the server would specify all
> the types it could accept, as you pointed out.
> 
> Best regards,
> James Salsman

David Singer
Multimedia and Software Standards, Apple Inc.