Talk:OggPCM Draft1 - Revision history

Jmspeex: trying to sort out the links

2006-03-07T06:09:30Z

trying to sort out the links

← Older revision		Revision as of 06:09, 7 March 2006
Line 70:		Line 70:
	--[[User:Erikd\|Erikd]]		--[[User:Erikd\|Erikd]]

-	* This issue has been resolved in the most recent [[~~OggPCM~~#Format\|Format]] draft; unsigned support is provided for 8bit samples only.	+	* This issue has been resolved in the most recent [[OggPCM_Draft1#Format\|Format]] draft; unsigned support is provided for 8bit samples only.
	--[[User:Arc\|Arc]] 23:39, 10 Nov 2005 (PST)		--[[User:Arc\|Arc]] 23:39, 10 Nov 2005 (PST)

Line 87:		Line 87:
	--[[User:Gumboot\|Gumboot]] 02:08, 10 Nov 2005 (PST)		--[[User:Gumboot\|Gumboot]] 02:08, 10 Nov 2005 (PST)

-	* This issue has been resolved in the most recent [[~~OggPCM~~#Format\|Format]] draft; float support is provided for 32bit and 64bit samples only.	+	* This issue has been resolved in the most recent [[OggPCM_Draft1#Format\|Format]] draft; float support is provided for 32bit and 64bit samples only.
	--[[User:Arc\|Arc]] 23:40, 10 Nov 2005 (PST)		--[[User:Arc\|Arc]] 23:40, 10 Nov 2005 (PST)

Line 105:		Line 105:
	--[[User:Erikd\|Erikd]]		--[[User:Erikd\|Erikd]]

-	* This issue has been resolved in the most recent [[~~OggPCM~~#Format\|Format]] draft; an endian flag is provided seperate from the data format, though it will not effect 8bit sample types.	+	* This issue has been resolved in the most recent [[OggPCM_Draft1#Format\|Format]] draft; an endian flag is provided seperate from the data format, though it will not effect 8bit sample types.
	--[[User:Arc\|Arc]] 23:42, 10 Nov 2005 (PST)		--[[User:Arc\|Arc]] 23:42, 10 Nov 2005 (PST)

Line 117:		Line 117:
	--[[User:Conrad\|Conrad]]		--[[User:Conrad\|Conrad]]

-	* A comment header, identical to vorbis's comment header, has been added to the most recent draft [[~~OggPCM~~#Format\|format]]	+	* A comment header, identical to vorbis's comment header, has been added to the most recent draft [[OggPCM_Draft1#Format\|format]]
	--[[User:Arc\|Arc]] 23:44, 10 Nov 2005 (PST)		--[[User:Arc\|Arc]] 23:44, 10 Nov 2005 (PST)

Line 131:		Line 131:
	--[[Erikd\|Erikd]]		--[[Erikd\|Erikd]]

-	* With the introduction of a data type lookup table for the most recent [[~~OggPCM~~#Format\|format]], float types of neither 32bit or 64bit size is no longer available. If other sizes of float are needed they may be added in a future minor revision with an extended type.	+	* With the introduction of a data type lookup table for the most recent [[OggPCM_Draft1#Format\|format]], float types of neither 32bit or 64bit size is no longer available. If other sizes of float are needed they may be added in a future minor revision with an extended type.
	--[[User:Arc\|Arc]] 23:46, 10 Nov 2005 (PST)		--[[User:Arc\|Arc]] 23:46, 10 Nov 2005 (PST)

Conrad: Talk:OggPCM moved to Talk:OggPCM Draft1

2006-02-22T01:15:06Z

Talk:OggPCM moved to Talk:OggPCM Draft1

← Older revision

Revision as of 01:15, 22 February 2006

Arc: /* Do we want/need the 32-bit data packet header? */

2005-11-13T09:10:48Z

Do we want/need the 32-bit data packet header?

← Older revision		Revision as of 09:10, 13 November 2005
Line 53:		Line 53:
	--[[User:Arc\|Arc]] 23:51, 10 Nov 2005 (PST)		--[[User:Arc\|Arc]] 23:51, 10 Nov 2005 (PST)

		+	* As to wether we need it, we need a way to mark header packets from data packets, as we need a comment header to carry comments from decoded Vorbis/FLAC/etc (or to be encoded to Vorbis/FLAC/etc). Erik's comment re: 64-bit floats is one I'd like to highlight yellow. Pending a check on libogg2 to see what 64-bit alignment is available on which platforms, we could:
		+	** Extend the data packet header to 64-bits, prehaps only with 64-bit data
		+	** Have a packet0 field which specifies how many header packets there are, as [[User:Conrad\|Conrad]] suggested
		+	** Have the last header packet of ID \xFF which marks the end of the headers
		+	--[[User:Arc\|Arc]] 01:10, 13 Nov 2005 (PST)

	=== Signed/Unsigned data flag? ===		=== Signed/Unsigned data flag? ===

Arc at 08:48, 13 November 2005

2005-11-13T08:48:26Z

Show changes

Arc: adding a second newline between sections

2005-11-11T07:53:15Z

adding a second newline between sections

Arc: /* Do we want/need the 32-bit data packet header? */

2005-11-11T07:52:05Z

Do we want/need the 32-bit data packet header?

← Older revision		Revision as of 07:52, 11 November 2005
Line 83:		Line 83:
	--[[User:Arc\|Arc]] 23:48, 10 Nov 2005 (PST)		--[[User:Arc\|Arc]] 23:48, 10 Nov 2005 (PST)

-	== Do we want/need the 32-bit data packet header? ==	+	=== Do we want/need the 32-bit data packet header? ===
	* The issue was raised on the ogg-dev mailing list of wether this is necessary. With only a single header packet, it could be considered an unneeded complication, however, additional header packets (current or future) will make this a requirement.		* The issue was raised on the ogg-dev mailing list of wether this is necessary. With only a single header packet, it could be considered an unneeded complication, however, additional header packets (current or future) will make this a requirement.
	--[[User:Arc\|Arc]]		--[[User:Arc\|Arc]]

Arc: /* Do we want/need the 32-bit data packet header? */

2005-11-11T07:51:33Z

Do we want/need the 32-bit data packet header?

← Older revision		Revision as of 07:51, 11 November 2005
Line 84:		Line 84:

	== Do we want/need the 32-bit data packet header? ==		== Do we want/need the 32-bit data packet header? ==
-	* The issue was raised on the ogg-dev mailing list of wether this is necessary. With only a single header packet, it could be considered an unneeded complication, however, additional header packets (current or future) will make this a requirement. --[[User:Arc\|Arc]]	+	* The issue was raised on the ogg-dev mailing list of wether this is necessary. With only a single header packet, it could be considered an unneeded complication, however, additional header packets (current or future) will make this a requirement.
		+	--[[User:Arc\|Arc]]

	* I can definitely see people wanting to use comment pages, so I'd say leave the header on the data pages as well. On the other hand, if ogg provides guarantees about the alignment of packet data from packetout, I could see getting rid of it since there are benefits to working on buffers aligned to larger boundaries on some architectures. As far as I can tell, either no guarantees are made, or you'll get a buffer aligned to a word boundary, in which case having the header has no penalty.		* I can definitely see people wanting to use comment pages, so I'd say leave the header on the data pages as well. On the other hand, if ogg provides guarantees about the alignment of packet data from packetout, I could see getting rid of it since there are benefits to working on buffers aligned to larger boundaries on some architectures. As far as I can tell, either no guarantees are made, or you'll get a buffer aligned to a word boundary, in which case having the header has no penalty.
Line 100:		Line 101:
	* This header is unnecessary. Ogg already provides packet framing, and the existing headers (BOS, comments) can be determined by sequence order. The BOS header already contains forwards compatability versioning for extra header fields. Even if new headers were to be created, they could be indicated by an 'extra_headers' field in the BOS header, as is done in Speex.		* This header is unnecessary. Ogg already provides packet framing, and the existing headers (BOS, comments) can be determined by sequence order. The BOS header already contains forwards compatability versioning for extra header fields. Even if new headers were to be created, they could be indicated by an 'extra_headers' field in the BOS header, as is done in Speex.
	--[[User:Conrad\|Conrad]]		--[[User:Conrad\|Conrad]]
		+
		+	* This issue remains one of few left contested, however, I believe that for uniformity with Vorbis and Theora, this is the correct method to identify packet types within the current version of the Ogg container.
		+	--[[User:Arc\|Arc]] 23:51, 10 Nov 2005 (PST)

Arc: /* Are samples padded to some round number of bits? */

2005-11-11T07:48:43Z

Are samples padded to some round number of bits?

← Older revision		Revision as of 07:48, 11 November 2005
Line 76:		Line 76:

	* 10-bit values have a range of -512 to +511. When you shift them up the range is -32768 to 32704, so they need scaling if you want them to have their proper range in a normalised system.		* 10-bit values have a range of -512 to +511. When you shift them up the range is -32768 to 32704, so they need scaling if you want them to have their proper range in a normalised system.
		+
	* Precisions that aren't a multiple of 8 bit aren't at all rare, but they're normally rounded off to a multiple for compatibility.		* Precisions that aren't a multiple of 8 bit aren't at all rare, but they're normally rounded off to a multiple for compatibility.
	--[[User:Gumboot\|Gumboot]] 02:02, 10 Nov 2005 (PST)		--[[User:Gumboot\|Gumboot]] 02:02, 10 Nov 2005 (PST)
		+
		+	* Support for non-octet based sample sizes has been removed with the introduction of a data type table. We no longer need to worry about this topic.
		+	--[[User:Arc\|Arc]] 23:48, 10 Nov 2005 (PST)

	== Do we want/need the 32-bit data packet header? ==		== Do we want/need the 32-bit data packet header? ==

Arc: /* How does one interpret a file where the Bits per Sample is neither 32 nor 64 and the Data Type is float? */

2005-11-11T07:46:37Z

How does one interpret a file where the Bits per Sample is neither 32 nor 64 and the Data Type is float?

← Older revision		Revision as of 07:46, 11 November 2005
Line 64:		Line 64:
	* Many file formats (WAV, AIFF, AU and others) support 64 bit float data. WAV stores floats as little endian data and AIFF stores if as big endian data. OggPCM should support both 32 and 64 bit floats of both endian-nesses (is that a word?). I don't know of any other floating point format that needs consideration.		* Many file formats (WAV, AIFF, AU and others) support 64 bit float data. WAV stores floats as little endian data and AIFF stores if as big endian data. OggPCM should support both 32 and 64 bit floats of both endian-nesses (is that a word?). I don't know of any other floating point format that needs consideration.
	--[[Erikd\|Erikd]]		--[[Erikd\|Erikd]]
		+
		+	* With the introduction of a data type lookup table for the most recent [[OggPCM#Format\|format]], float types of neither 32bit or 64bit size is no longer available. If other sizes of float are needed they may be added in a future minor revision with an extended type.
		+	--[[User:Arc\|Arc]] 23:46, 10 Nov 2005 (PST)

	=== Are samples padded to some round number of bits? ===		=== Are samples padded to some round number of bits? ===

Arc: /* Is it worth supporting a vorbiscomment header? */

2005-11-11T07:44:41Z

Is it worth supporting a vorbiscomment header?

← Older revision		Revision as of 07:44, 11 November 2005
Line 51:		Line 51:
	* Agree		* Agree
	--[[User:Conrad\|Conrad]]		--[[User:Conrad\|Conrad]]
		+
		+	* A comment header, identical to vorbis's comment header, has been added to the most recent draft [[OggPCM#Format\|format]]
		+	--[[User:Arc\|Arc]] 23:44, 10 Nov 2005 (PST)

	=== How does one interpret a file where the Bits per Sample is neither 32 nor 64 and the Data Type is float? ===		=== How does one interpret a file where the Bits per Sample is neither 32 nor 64 and the Data Type is float? ===

← Older revision		Revision as of 06:09, 7 March 2006
Line 70:		Line 70:
	--[[User:Erikd\|Erikd]]		--[[User:Erikd\|Erikd]]

-	* This issue has been resolved in the most recent [[~~OggPCM~~#Format\|Format]] draft; unsigned support is provided for 8bit samples only.	+	* This issue has been resolved in the most recent [[OggPCM_Draft1#Format\|Format]] draft; unsigned support is provided for 8bit samples only.
	--[[User:Arc\|Arc]] 23:39, 10 Nov 2005 (PST)		--[[User:Arc\|Arc]] 23:39, 10 Nov 2005 (PST)

Line 87:		Line 87:
	--[[User:Gumboot\|Gumboot]] 02:08, 10 Nov 2005 (PST)		--[[User:Gumboot\|Gumboot]] 02:08, 10 Nov 2005 (PST)

-	* This issue has been resolved in the most recent [[~~OggPCM~~#Format\|Format]] draft; float support is provided for 32bit and 64bit samples only.	+	* This issue has been resolved in the most recent [[OggPCM_Draft1#Format\|Format]] draft; float support is provided for 32bit and 64bit samples only.
	--[[User:Arc\|Arc]] 23:40, 10 Nov 2005 (PST)		--[[User:Arc\|Arc]] 23:40, 10 Nov 2005 (PST)

Line 105:		Line 105:
	--[[User:Erikd\|Erikd]]		--[[User:Erikd\|Erikd]]

-	* This issue has been resolved in the most recent [[~~OggPCM~~#Format\|Format]] draft; an endian flag is provided seperate from the data format, though it will not effect 8bit sample types.	+	* This issue has been resolved in the most recent [[OggPCM_Draft1#Format\|Format]] draft; an endian flag is provided seperate from the data format, though it will not effect 8bit sample types.
	--[[User:Arc\|Arc]] 23:42, 10 Nov 2005 (PST)		--[[User:Arc\|Arc]] 23:42, 10 Nov 2005 (PST)

Line 117:		Line 117:
	--[[User:Conrad\|Conrad]]		--[[User:Conrad\|Conrad]]

-	* A comment header, identical to vorbis's comment header, has been added to the most recent draft [[~~OggPCM~~#Format\|format]]	+	* A comment header, identical to vorbis's comment header, has been added to the most recent draft [[OggPCM_Draft1#Format\|format]]
	--[[User:Arc\|Arc]] 23:44, 10 Nov 2005 (PST)		--[[User:Arc\|Arc]] 23:44, 10 Nov 2005 (PST)

Line 131:		Line 131:
	--[[Erikd\|Erikd]]		--[[Erikd\|Erikd]]

-	* With the introduction of a data type lookup table for the most recent [[~~OggPCM~~#Format\|format]], float types of neither 32bit or 64bit size is no longer available. If other sizes of float are needed they may be added in a future minor revision with an extended type.	+	* With the introduction of a data type lookup table for the most recent [[OggPCM_Draft1#Format\|format]], float types of neither 32bit or 64bit size is no longer available. If other sizes of float are needed they may be added in a future minor revision with an extended type.
	--[[User:Arc\|Arc]] 23:46, 10 Nov 2005 (PST)		--[[User:Arc\|Arc]] 23:46, 10 Nov 2005 (PST)

← Older revision		Revision as of 07:53, 11 November 2005
Line 12:		Line 12:
	* This issue has been resolved in the most recent [[OggPCM#Format\|Format]] draft; unsigned support is provided for 8bit samples only.		* This issue has been resolved in the most recent [[OggPCM#Format\|Format]] draft; unsigned support is provided for 8bit samples only.
	--[[User:Arc\|Arc]] 23:39, 10 Nov 2005 (PST)		--[[User:Arc\|Arc]] 23:39, 10 Nov 2005 (PST)
		+

	=== Do we need to record int/float data flag? ===		=== Do we need to record int/float data flag? ===
Line 26:		Line 27:
	* This issue has been resolved in the most recent [[OggPCM#Format\|Format]] draft; float support is provided for 32bit and 64bit samples only.		* This issue has been resolved in the most recent [[OggPCM#Format\|Format]] draft; float support is provided for 32bit and 64bit samples only.
	--[[User:Arc\|Arc]] 23:40, 10 Nov 2005 (PST)		--[[User:Arc\|Arc]] 23:40, 10 Nov 2005 (PST)
		+

	=== Do we need to offer endian data flag? If not, which is used? ===		=== Do we need to offer endian data flag? If not, which is used? ===
Line 43:		Line 45:
	* This issue has been resolved in the most recent [[OggPCM#Format\|Format]] draft; an endian flag is provided seperate from the data format, though it will not effect 8bit sample types.		* This issue has been resolved in the most recent [[OggPCM#Format\|Format]] draft; an endian flag is provided seperate from the data format, though it will not effect 8bit sample types.
	--[[User:Arc\|Arc]] 23:42, 10 Nov 2005 (PST)		--[[User:Arc\|Arc]] 23:42, 10 Nov 2005 (PST)
		+

	=== Is it worth supporting a vorbiscomment header? ===		=== Is it worth supporting a vorbiscomment header? ===
Line 54:		Line 57:
	* A comment header, identical to vorbis's comment header, has been added to the most recent draft [[OggPCM#Format\|format]]		* A comment header, identical to vorbis's comment header, has been added to the most recent draft [[OggPCM#Format\|format]]
	--[[User:Arc\|Arc]] 23:44, 10 Nov 2005 (PST)		--[[User:Arc\|Arc]] 23:44, 10 Nov 2005 (PST)
		+

	=== How does one interpret a file where the Bits per Sample is neither 32 nor 64 and the Data Type is float? ===		=== How does one interpret a file where the Bits per Sample is neither 32 nor 64 and the Data Type is float? ===
Line 67:		Line 71:
	* With the introduction of a data type lookup table for the most recent [[OggPCM#Format\|format]], float types of neither 32bit or 64bit size is no longer available. If other sizes of float are needed they may be added in a future minor revision with an extended type.		* With the introduction of a data type lookup table for the most recent [[OggPCM#Format\|format]], float types of neither 32bit or 64bit size is no longer available. If other sizes of float are needed they may be added in a future minor revision with an extended type.
	--[[User:Arc\|Arc]] 23:46, 10 Nov 2005 (PST)		--[[User:Arc\|Arc]] 23:46, 10 Nov 2005 (PST)
		+

	=== Are samples padded to some round number of bits? ===		=== Are samples padded to some round number of bits? ===
Line 82:		Line 87:
	* Support for non-octet based sample sizes has been removed with the introduction of a data type table. We no longer need to worry about this topic.		* Support for non-octet based sample sizes has been removed with the introduction of a data type table. We no longer need to worry about this topic.
	--[[User:Arc\|Arc]] 23:48, 10 Nov 2005 (PST)		--[[User:Arc\|Arc]] 23:48, 10 Nov 2005 (PST)
		+

	=== Do we want/need the 32-bit data packet header? ===		=== Do we want/need the 32-bit data packet header? ===