[gst-devel] audio/raw vs float

[Erik Walthinsen]

On Mon, 19 Mar 2001, Steve Baker wrote:

> So, what if we create a new mime type audio/float with these properties:
> format - an enum including standard 32 bit and 64 bit formats.  New formats
> can be included in future releases.
> lower-bound - usually -1.0 (sometimes 0.0)
> upper-bound - usually 1.0
> rate - The sample rate of the data, in samples per second.
> channels - The number of channels of audio data.
>
> I think it is justified to have a seperate mime type for audio float data
> since plugins that support both int and float will have to duplicate
> functionality for both types anyway.

I tend to agree here.  audio/raw is generally assumed to be integer, and
trying to merge the properties between integer and float doesn't look fun.
The properties you suggest seem like they should cover everything, but
it's worth doing some web searches for things like SMPTE and AES/BEU
standards, even M$'s pages (they have some interesting stuff on
multi-channel formats within the WAV structures already in Windoze).

One other thought I had is that it might be very useful to include channel
labels as properties.  For instance, if you bother, you might label one
stream with channel 0 as 'left' or 'L' and channel 1 as 'right' or 'R'.
Other labelings include M,S (mid-side), L,C,R,Ls,Rs,S (5.1 surround),
M,X,Y,Z (low order ambisonics), etc.  These could simply be properties
such as:

  "label0", GST_PROP_STRING ("L"),
  "label1", GST_PROP_STRING ("R"),

This could introduce the problem of explaining to the props system the
difference between properties that have to match, and those that don't.
Then again, it might be good to force a match for labels like these, so
you don't mix an L,R pair with a M,S pair.  Thoughts?

      Erik Walthinsen <omega at temple-baptist.com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_