- From: David Singer <singer@apple.com>
- Date: Wed, 1 Sep 2010 12:34:43 -0700
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.
Received on Wednesday, 1 September 2010 12:34:43 UTC