Displaying 5 results from an estimated 5 matches for "ogg_pcm_s16".
2005 Nov 09
8
OggPCM proposal feedback
...eparate fields for things like signed/
unsigned/float and bit width is a mistake. I would suggest
instead a single field that encodes all this information
in a enumeration. Ie:
OGG_PCM_U8 /* Unsigned 8 bit */
OGG_PCM_S8 /* Signed 8 bit. */
OGG_PCM_S16
OGG_PCM_S24
OGG_PCM_S32
OGG_PCM_FLOAT32
OGG_PCM_FLOAT64
and so on. This scheme makes it very difficult to get
signed/unsigned and bitwith messed up.
d) Don't bother implementing unsigned PCM for bit widths
greater than 8 bits. No other comm...
2005 Nov 10
5
OggPCM proposal feedback
...nd bit width is a mistake. I would suggest
> > instead a single field that encodes all this information
> > in a enumeration. Ie:
> >
> > OGG_PCM_U8 /* Unsigned 8 bit */
> > OGG_PCM_S8 /* Signed 8 bit. */
> > OGG_PCM_S16
> > OGG_PCM_S24
> > OGG_PCM_S32
> > OGG_PCM_FLOAT32
> > OGG_PCM_FLOAT64
> >
> > and so on. This scheme makes it very difficult to get
> > signed/unsigned and bitwith messed up.
You didn't address this iss...
2005 Nov 09
0
OggPCM proposal feedback
...ed/
> unsigned/float and bit width is a mistake. I would suggest
> instead a single field that encodes all this information
> in a enumeration. Ie:
>
> OGG_PCM_U8 /* Unsigned 8 bit */
> OGG_PCM_S8 /* Signed 8 bit. */
> OGG_PCM_S16
> OGG_PCM_S24
> OGG_PCM_S32
> OGG_PCM_FLOAT32
> OGG_PCM_FLOAT64
>
> and so on. This scheme makes it very difficult to get
> signed/unsigned and bitwith messed up.
> d) Don't bother implementing unsigned PCM for bit widths...
2005 Nov 11
0
OggPCM proposal feedback
...signed/
> unsigned/float and bit width is a mistake. I would suggest
> instead a single field that encodes all this information
> in a enumeration. Ie:
>
> OGG_PCM_U8 /* Unsigned 8 bit */
> OGG_PCM_S8 /* Signed 8 bit. */
> OGG_PCM_S16
> OGG_PCM_S24
> OGG_PCM_S32
> OGG_PCM_FLOAT32
> OGG_PCM_FLOAT64
>
> and so on. This scheme makes it very difficult to get
> signed/unsigned and bitwith messed up.
With the exception of the top two being inverted, these tables look iden...
2005 Nov 11
2
OggPCM proposal feedback
Arc wrote:
> Ok so we cap it to 64bit, since much more than that doesn't make sense (96bit
> would be a "long double" C type)
On x86 CPUs, "long double" is 80 bits.
> I really don't like this idea, but I will entertain, formatting it as follows:
>
> ID Type Bits
> 0 Int 8
> 1 uInt 8
> 2 Int 16
> 3 Int 24
> 4 Int