https://wiki.xiph.org/api.php?action=feedcontributions&user=Gumboot&feedformat=atomXiphWiki - User contributions [en]2024-03-19T02:43:31ZUser contributionsMediaWiki 1.40.1https://wiki.xiph.org/index.php?title=Talk:TransOgg_Page&diff=12646Talk:TransOgg Page2010-10-17T10:59:48Z<p>Gumboot: /* Checksum */ SIMD please.</p>
<hr />
<div>==Checksum==<br />
I would recommend changing the checksum polynomial.<br />
<br />
For the range of page sizes possible in transogg the CRC-32C (Castagnoli) polynomial offers superior error detection ability over the 802.3 CRC32 that we currently have specified. This polynomial is also used by SCTP and iSCSI, so I could wave my arms and suggest that it might be more likely to get hardware assistance (ethernet CRC is usually done on the adaptor, but the SCTP and iSCSI crc can't be easily offloaded) ... but no armwaving is required: i7 has an instruction for the Castagnoli polynomial. There are superior polys to the iSCSI one, at least for some sizes relevant to us[http://www.ece.cmu.edu/~koopman/networks/dsn02/dsn02_koopman.pdf], but they lack obvious prospects of hardware assistance. <br />
<br />
Upsides to switching to Castagnoli CRC:<br />
* Faster CRC on some hardware<br />
* Increased error detection <br />
<br />
Upsides to switching to another improved CRC:<br />
* (Possibly) Increased error detection over Castagnoli<br />
<br />
Upsides to staying with current CRC:<br />
* Decreased implementation size and complexity for something also supporting the ogg format<br />
<br />
...though supporting multiple generator polynomials in a typical software implementation isn't hard.<br />
--[[User:Gmaxwell|Gmaxwell]] 06:56, 29 May 2010 (UTC)<br />
: If a message protected by a CRC fails to detect an error, then that message wrapped in header and footer and protected by the same CRC polynomial will fail to detect that same error. I think it should also be true that if that original message is split across several wrapper packets but the error appears entirely within one fragment, then the wrapper will still fail to detect the error. I think that's a strong case for avoiding 802.3's polynomial, but I'd suggest avoiding any popular polynomial, to extend the principle to other media with other polynomials. I think a case could also be made for ignoring the low-BER assumption in choosing a polynomial, because that should already be handled by layers closer to the media. A pure hash is all that is needed here. In fact, do we just want a fast hash instead of a CRC? --[[User:Gumboot|Gumboot]] 09:09, 17 October 2010 (UTC)<br />
:: If there is a movement towards a non-CRC hash, please be careful to select something SIMDable. --[[User:Gumboot|Gumboot]] 10:59, 17 October 2010 (UTC)<br />
<br />
== Arrange checksum order for fast page edits of essential data ==<br />
<br />
IP allows fast editing of packets by using a checksum that isn't order-sensitive, so you can subtract the old value and add the new value of any given field directly to the checksum without having to re-sum the whole packet. CRC allows the same thing using EOR, but the modification to the checksum depends both the data and its distance to the end of the checked block. If data which is likely to be edited in a repetitive way over many pages is stored at a fixed distance to the ''end'' of the checksum block then the checksum delta can be pre-computed and applied directly without recalculation.<br />
<br />
At least two ideas have been discussed so far:<br />
#checksum payload, then variable-length header content, then fixed-length header<br />
#checksum different components separately and EOR them together in an order-insensitive way, or EOR them with length-agnostic perturbations which preserve the useful error-detection features of a CRC.<br />
<br />
Note that some CRC libraries and accelerators will have overheads that restrict their ability to accumulate data in a random order. They're likely to prefer well-aligned data and long runs of conventionally-ordered data. An ideal solution wouldn't interfere with their operation unnecessarily. --[[User:Gumboot|Gumboot]] 12:14, 4 June 2010 (UTC)<br />
:I guess we should figure out what fields people would want to change cheaply. The lacing, for example, isn't going to get changed without changing the data. I think the obvious cases include the DTS (among other things) and that's currently a variable length field. --[[User:Gmaxwell|Gmaxwell]] 15:06, 4 June 2010 (UTC)<br />
::All I had in mind was the stream ID. In fact, perhaps making it easily editable would be preferable to making it large enough that it rarely needs to be changed.<br />
::Of course this is much easier for changing fields from one constant to another. If various bits change in different ways from page to page then you need a larger table of twiddles to mash into the CRC.<br />
::If it's still a desirable feature, then you can use a set of tables to edit each bit in the relevant field, or some collection of those tables representing the adjustment for various distances from the end of the checksum, and the only requirement would be that the possible distances can be constrained. --[[User:Gumboot|Gumboot]] 22:35, 4 June 2010 (UTC)<br />
::Actually it is desirable, even if it is just for the stream ID. You'll win over no embedded programmers with the promise of rarely doing a lot of work rather than always doing a little, and you'll never guarantee that stream ID rewrites will be performed by all software when necessary when they're only necessary very infrequently. --[[User:Gumboot|Gumboot]] 09:14, 22 September 2010 (UTC)</div>Gumboothttps://wiki.xiph.org/index.php?title=Talk:TransOgg_Page&diff=12643Talk:TransOgg Page2010-10-17T09:29:47Z<p>Gumboot: /* Checksum */</p>
<hr />
<div>==Checksum==<br />
I would recommend changing the checksum polynomial.<br />
<br />
For the range of page sizes possible in transogg the CRC-32C (Castagnoli) polynomial offers superior error detection ability over the 802.3 CRC32 that we currently have specified. This polynomial is also used by SCTP and iSCSI, so I could wave my arms and suggest that it might be more likely to get hardware assistance (ethernet CRC is usually done on the adaptor, but the SCTP and iSCSI crc can't be easily offloaded) ... but no armwaving is required: i7 has an instruction for the Castagnoli polynomial. There are superior polys to the iSCSI one, at least for some sizes relevant to us[http://www.ece.cmu.edu/~koopman/networks/dsn02/dsn02_koopman.pdf], but they lack obvious prospects of hardware assistance. <br />
<br />
Upsides to switching to Castagnoli CRC:<br />
* Faster CRC on some hardware<br />
* Increased error detection <br />
<br />
Upsides to switching to another improved CRC:<br />
* (Possibly) Increased error detection over Castagnoli<br />
<br />
Upsides to staying with current CRC:<br />
* Decreased implementation size and complexity for something also supporting the ogg format<br />
<br />
...though supporting multiple generator polynomials in a typical software implementation isn't hard.<br />
--[[User:Gmaxwell|Gmaxwell]] 06:56, 29 May 2010 (UTC)<br />
: If a message protected by a CRC fails to detect an error, then that message wrapped in header and footer and protected by the same CRC polynomial will fail to detect that same error. I think it should also be true that if that original message is split across several wrapper packets but the error appears entirely within one fragment, then the wrapper will still fail to detect the error. I think that's a strong case for avoiding 802.3's polynomial, but I'd suggest avoiding any popular polynomial, to extend the principle to other media with other polynomials. I think a case could also be made for ignoring the low-BER assumption in choosing a polynomial, because that should already be handled by layers closer to the media. A pure hash is all that is needed here. In fact, do we just want a fast hash instead of a CRC? --[[User:Gumboot|Gumboot]] 09:09, 17 October 2010 (UTC)<br />
<br />
== Arrange checksum order for fast page edits of essential data ==<br />
<br />
IP allows fast editing of packets by using a checksum that isn't order-sensitive, so you can subtract the old value and add the new value of any given field directly to the checksum without having to re-sum the whole packet. CRC allows the same thing using EOR, but the modification to the checksum depends both the data and its distance to the end of the checked block. If data which is likely to be edited in a repetitive way over many pages is stored at a fixed distance to the ''end'' of the checksum block then the checksum delta can be pre-computed and applied directly without recalculation.<br />
<br />
At least two ideas have been discussed so far:<br />
#checksum payload, then variable-length header content, then fixed-length header<br />
#checksum different components separately and EOR them together in an order-insensitive way, or EOR them with length-agnostic perturbations which preserve the useful error-detection features of a CRC.<br />
<br />
Note that some CRC libraries and accelerators will have overheads that restrict their ability to accumulate data in a random order. They're likely to prefer well-aligned data and long runs of conventionally-ordered data. An ideal solution wouldn't interfere with their operation unnecessarily. --[[User:Gumboot|Gumboot]] 12:14, 4 June 2010 (UTC)<br />
:I guess we should figure out what fields people would want to change cheaply. The lacing, for example, isn't going to get changed without changing the data. I think the obvious cases include the DTS (among other things) and that's currently a variable length field. --[[User:Gmaxwell|Gmaxwell]] 15:06, 4 June 2010 (UTC)<br />
::All I had in mind was the stream ID. In fact, perhaps making it easily editable would be preferable to making it large enough that it rarely needs to be changed.<br />
::Of course this is much easier for changing fields from one constant to another. If various bits change in different ways from page to page then you need a larger table of twiddles to mash into the CRC.<br />
::If it's still a desirable feature, then you can use a set of tables to edit each bit in the relevant field, or some collection of those tables representing the adjustment for various distances from the end of the checksum, and the only requirement would be that the possible distances can be constrained. --[[User:Gumboot|Gumboot]] 22:35, 4 June 2010 (UTC)<br />
::Actually it is desirable, even if it is just for the stream ID. You'll win over no embedded programmers with the promise of rarely doing a lot of work rather than always doing a little, and you'll never guarantee that stream ID rewrites will be performed by all software when necessary when they're only necessary very infrequently. --[[User:Gumboot|Gumboot]] 09:14, 22 September 2010 (UTC)</div>Gumboothttps://wiki.xiph.org/index.php?title=Talk:TransOgg_Page&diff=12642Talk:TransOgg Page2010-10-17T09:10:15Z<p>Gumboot: /* Checksum */</p>
<hr />
<div>==Checksum==<br />
I would recommend changing the checksum polynomial.<br />
<br />
For the range of page sizes possible in transogg the CRC-32C (Castagnoli) polynomial offers superior error detection ability over the 802.3 CRC32 that we currently have specified. This polynomial is also used by SCTP and iSCSI, so I could wave my arms and suggest that it might be more likely to get hardware assistance (ethernet CRC is usually done on the adaptor, but the SCTP and iSCSI crc can't be easily offloaded) ... but no armwaving is required: i7 has an instruction for the Castagnoli polynomial. There are superior polys to the iSCSI one, at least for some sizes relevant to us[http://www.ece.cmu.edu/~koopman/networks/dsn02/dsn02_koopman.pdf], but they lack obvious prospects of hardware assistance. <br />
<br />
Upsides to switching to Castagnoli CRC:<br />
* Faster CRC on some hardware<br />
* Increased error detection <br />
<br />
Upsides to switching to another improved CRC:<br />
* (Possibly) Increased error detection over Castagnoli<br />
<br />
Upsides to staying with current CRC:<br />
* Decreased implementation size and complexity for something also supporting the ogg format<br />
<br />
...though supporting multiple generator polynomials in a typical software implementation isn't hard.<br />
--[[User:Gmaxwell|Gmaxwell]] 06:56, 29 May 2010 (UTC)<br />
: If a message protected by a CRC fails to detect an error, then that message wrapped in header and footer and protected by the same CRC polynomial will fail to detect that same error. I think it should also be true that if that original message is split across several wrapper packets but the error appears entirely within one fragment, then the wrapper will still fail to detect the error. I think that's a strong case for avoiding 802.3's polynomial, but I'd suggest avoiding any popular polynomial for extension onto other media. I think a case could also be made for ignoring the low-BER assumption in choosing a polynomial, because that should already be handled by layers closer to the media. A pure hash is all that is needed here. In fact, do we just want a fast hash instead of a CRC? --[[User:Gumboot|Gumboot]] 09:09, 17 October 2010 (UTC)<br />
<br />
== Arrange checksum order for fast page edits of essential data ==<br />
<br />
IP allows fast editing of packets by using a checksum that isn't order-sensitive, so you can subtract the old value and add the new value of any given field directly to the checksum without having to re-sum the whole packet. CRC allows the same thing using EOR, but the modification to the checksum depends both the data and its distance to the end of the checked block. If data which is likely to be edited in a repetitive way over many pages is stored at a fixed distance to the ''end'' of the checksum block then the checksum delta can be pre-computed and applied directly without recalculation.<br />
<br />
At least two ideas have been discussed so far:<br />
#checksum payload, then variable-length header content, then fixed-length header<br />
#checksum different components separately and EOR them together in an order-insensitive way, or EOR them with length-agnostic perturbations which preserve the useful error-detection features of a CRC.<br />
<br />
Note that some CRC libraries and accelerators will have overheads that restrict their ability to accumulate data in a random order. They're likely to prefer well-aligned data and long runs of conventionally-ordered data. An ideal solution wouldn't interfere with their operation unnecessarily. --[[User:Gumboot|Gumboot]] 12:14, 4 June 2010 (UTC)<br />
:I guess we should figure out what fields people would want to change cheaply. The lacing, for example, isn't going to get changed without changing the data. I think the obvious cases include the DTS (among other things) and that's currently a variable length field. --[[User:Gmaxwell|Gmaxwell]] 15:06, 4 June 2010 (UTC)<br />
::All I had in mind was the stream ID. In fact, perhaps making it easily editable would be preferable to making it large enough that it rarely needs to be changed.<br />
::Of course this is much easier for changing fields from one constant to another. If various bits change in different ways from page to page then you need a larger table of twiddles to mash into the CRC.<br />
::If it's still a desirable feature, then you can use a set of tables to edit each bit in the relevant field, or some collection of those tables representing the adjustment for various distances from the end of the checksum, and the only requirement would be that the possible distances can be constrained. --[[User:Gumboot|Gumboot]] 22:35, 4 June 2010 (UTC)<br />
::Actually it is desirable, even if it is just for the stream ID. You'll win over no embedded programmers with the promise of rarely doing a lot of work rather than always doing a little, and you'll never guarantee that stream ID rewrites will be performed by all software when necessary when they're only necessary very infrequently. --[[User:Gumboot|Gumboot]] 09:14, 22 September 2010 (UTC)</div>Gumboothttps://wiki.xiph.org/index.php?title=Talk:TransOgg_Page&diff=12641Talk:TransOgg Page2010-10-17T09:09:37Z<p>Gumboot: /* Checksum */ Avoid popular polynomials.</p>
<hr />
<div>==Checksum==<br />
I would recommend changing the checksum polynomial.<br />
<br />
For the range of page sizes possible in transogg the CRC-32C (Castagnoli) polynomial offers superior error detection ability over the 802.3 CRC32 that we currently have specified. This polynomial is also used by SCTP and iSCSI, so I could wave my arms and suggest that it might be more likely to get hardware assistance (ethernet CRC is usually done on the adaptor, but the SCTP and iSCSI crc can't be easily offloaded) ... but no armwaving is required: i7 has an instruction for the Castagnoli polynomial. There are superior polys to the iSCSI one, at least for some sizes relevant to us[http://www.ece.cmu.edu/~koopman/networks/dsn02/dsn02_koopman.pdf], but they lack obvious prospects of hardware assistance. <br />
<br />
Upsides to switching to Castagnoli CRC:<br />
* Faster CRC on some hardware<br />
* Increased error detection <br />
<br />
Upsides to switching to another improved CRC:<br />
* (Possibly) Increased error detection over Castagnoli<br />
<br />
Upsides to staying with current CRC:<br />
* Decreased implementation size and complexity for something also supporting the ogg format<br />
<br />
...though supporting multiple generator polynomials in a typical software implementation isn't hard.<br />
--[[User:Gmaxwell|Gmaxwell]] 06:56, 29 May 2010 (UTC)<br />
: If a message protected by a CRC fails to detect an error, then that message wrapped in header and footer and protected by the same CRC polynomial will fail to detect that same error. I think it should also be true that if that original message is split across several wrapper packets but the error appears entirely within one fragment, then the wrapper will still fail to detect the error. I think that's a strong case for avoiding 802.3's polynomial, but I'd suggest avoiding any popular polynomial for extension onto other media. I think a case could also be made for ignoring the low-BER assumption in choosing a polynomial, because that should already be handled by the medium. A pure hash is all that is needed here. In fact, do we just want a fast hash instead of a CRC? --[[User:Gumboot|Gumboot]] 09:09, 17 October 2010 (UTC)<br />
<br />
== Arrange checksum order for fast page edits of essential data ==<br />
<br />
IP allows fast editing of packets by using a checksum that isn't order-sensitive, so you can subtract the old value and add the new value of any given field directly to the checksum without having to re-sum the whole packet. CRC allows the same thing using EOR, but the modification to the checksum depends both the data and its distance to the end of the checked block. If data which is likely to be edited in a repetitive way over many pages is stored at a fixed distance to the ''end'' of the checksum block then the checksum delta can be pre-computed and applied directly without recalculation.<br />
<br />
At least two ideas have been discussed so far:<br />
#checksum payload, then variable-length header content, then fixed-length header<br />
#checksum different components separately and EOR them together in an order-insensitive way, or EOR them with length-agnostic perturbations which preserve the useful error-detection features of a CRC.<br />
<br />
Note that some CRC libraries and accelerators will have overheads that restrict their ability to accumulate data in a random order. They're likely to prefer well-aligned data and long runs of conventionally-ordered data. An ideal solution wouldn't interfere with their operation unnecessarily. --[[User:Gumboot|Gumboot]] 12:14, 4 June 2010 (UTC)<br />
:I guess we should figure out what fields people would want to change cheaply. The lacing, for example, isn't going to get changed without changing the data. I think the obvious cases include the DTS (among other things) and that's currently a variable length field. --[[User:Gmaxwell|Gmaxwell]] 15:06, 4 June 2010 (UTC)<br />
::All I had in mind was the stream ID. In fact, perhaps making it easily editable would be preferable to making it large enough that it rarely needs to be changed.<br />
::Of course this is much easier for changing fields from one constant to another. If various bits change in different ways from page to page then you need a larger table of twiddles to mash into the CRC.<br />
::If it's still a desirable feature, then you can use a set of tables to edit each bit in the relevant field, or some collection of those tables representing the adjustment for various distances from the end of the checksum, and the only requirement would be that the possible distances can be constrained. --[[User:Gumboot|Gumboot]] 22:35, 4 June 2010 (UTC)<br />
::Actually it is desirable, even if it is just for the stream ID. You'll win over no embedded programmers with the promise of rarely doing a lot of work rather than always doing a little, and you'll never guarantee that stream ID rewrites will be performed by all software when necessary when they're only necessary very infrequently. --[[User:Gumboot|Gumboot]] 09:14, 22 September 2010 (UTC)</div>Gumboothttps://wiki.xiph.org/index.php?title=Talk:TransOgg_Page&diff=12477Talk:TransOgg Page2010-09-22T09:14:40Z<p>Gumboot: /* Arrange checksum order for fast page edits of essential data */ Prefer mandatory stream ID rewrites.</p>
<hr />
<div>==Checksum==<br />
I would recommend changing the checksum polynomial.<br />
<br />
For the range of page sizes possible in transogg the CRC-32C (Castagnoli) polynomial offers superior error detection ability over the 802.3 CRC32 that we currently have specified. This polynomial is also used by SCTP and iSCSI, so I could wave my arms and suggest that it might be more likely to get hardware assistance (ethernet CRC is usually done on the adaptor, but the SCTP and iSCSI crc can't be easily offloaded) ... but no armwaving is required: i7 has an instruction for the Castagnoli polynomial. There are superior polys to the iSCSI one, at least for some sizes relevant to us[http://www.ece.cmu.edu/~koopman/networks/dsn02/dsn02_koopman.pdf], but they lack obvious prospects of hardware assistance. <br />
<br />
Upsides to switching to Castagnoli CRC:<br />
* Faster CRC on some hardware<br />
* Increased error detection <br />
<br />
Upsides to switching to another improved CRC:<br />
* (Possibly) Increased error detection over Castagnoli<br />
<br />
Upsides to staying with current CRC:<br />
* Decreased implementation size and complexity for something also supporting the ogg format<br />
<br />
...though supporting multiple generator polynomials in a typical software implementation isn't hard.<br />
--[[User:Gmaxwell|Gmaxwell]] 06:56, 29 May 2010 (UTC)<br />
<br />
== Arrange checksum order for fast page edits of essential data ==<br />
<br />
IP allows fast editing of packets by using a checksum that isn't order-sensitive, so you can subtract the old value and add the new value of any given field directly to the checksum without having to re-sum the whole packet. CRC allows the same thing using EOR, but the modification to the checksum depends both the data and its distance to the end of the checked block. If data which is likely to be edited in a repetitive way over many pages is stored at a fixed distance to the ''end'' of the checksum block then the checksum delta can be pre-computed and applied directly without recalculation.<br />
<br />
At least two ideas have been discussed so far:<br />
#checksum payload, then variable-length header content, then fixed-length header<br />
#checksum different components separately and EOR them together in an order-insensitive way, or EOR them with length-agnostic perturbations which preserve the useful error-detection features of a CRC.<br />
<br />
Note that some CRC libraries and accelerators will have overheads that restrict their ability to accumulate data in a random order. They're likely to prefer well-aligned data and long runs of conventionally-ordered data. An ideal solution wouldn't interfere with their operation unnecessarily. --[[User:Gumboot|Gumboot]] 12:14, 4 June 2010 (UTC)<br />
:I guess we should figure out what fields people would want to change cheaply. The lacing, for example, isn't going to get changed without changing the data. I think the obvious cases include the DTS (among other things) and that's currently a variable length field. --[[User:Gmaxwell|Gmaxwell]] 15:06, 4 June 2010 (UTC)<br />
::All I had in mind was the stream ID. In fact, perhaps making it easily editable would be preferable to making it large enough that it rarely needs to be changed.<br />
::Of course this is much easier for changing fields from one constant to another. If various bits change in different ways from page to page then you need a larger table of twiddles to mash into the CRC.<br />
::If it's still a desirable feature, then you can use a set of tables to edit each bit in the relevant field, or some collection of those tables representing the adjustment for various distances from the end of the checksum, and the only requirement would be that the possible distances can be constrained. --[[User:Gumboot|Gumboot]] 22:35, 4 June 2010 (UTC)<br />
::Actually it is desirable, even if it is just for the stream ID. You'll win over no embedded programmers with the promise of rarely doing a lot of work rather than always doing a little, and you'll never guarantee that stream ID rewrites will be performed by all software when necessary when they're only necessary very infrequently. --[[User:Gumboot|Gumboot]] 09:14, 22 September 2010 (UTC)</div>Gumboothttps://wiki.xiph.org/index.php?title=Talk:TransOgg_Page&diff=12226Talk:TransOgg Page2010-06-04T22:35:53Z<p>Gumboot: /* Arrange checksum order for fast page edits of essential data */</p>
<hr />
<div>==Checksum==<br />
I would recommend changing the checksum polynomial.<br />
<br />
For the range of page sizes possible in transogg the CRC-32C (Castagnoli) polynomial offers superior error detection ability over the 802.3 CRC32 that we currently have specified. This polynomial is also used by SCTP and iSCSI, so I could wave my arms and suggest that it might be more likely to get hardware assistance (ethernet CRC is usually done on the adaptor, but the SCTP and iSCSI crc can't be easily offloaded) ... but no armwaving is required: i7 has an instruction for the Castagnoli polynomial. There are superior polys to the iSCSI one, at least for some sizes relevant to us[http://www.ece.cmu.edu/~koopman/networks/dsn02/dsn02_koopman.pdf], but they lack obvious prospects of hardware assistance. <br />
<br />
Upsides to switching to Castagnoli CRC:<br />
* Faster CRC on some hardware<br />
* Increased error detection <br />
<br />
Upsides to switching to another improved CRC:<br />
* (Possibly) Increased error detection over Castagnoli<br />
<br />
Upsides to staying with current CRC:<br />
* Decreased implementation size and complexity for something also supporting the ogg format<br />
<br />
...though supporting multiple generator polynomials in a typical software implementation isn't hard.<br />
--[[User:Gmaxwell|Gmaxwell]] 06:56, 29 May 2010 (UTC)<br />
<br />
== Arrange checksum order for fast page edits of essential data ==<br />
<br />
IP allows fast editing of packets by using a checksum that isn't order-sensitive, so you can subtract the old value and add the new value of any given field directly to the checksum without having to re-sum the whole packet. CRC allows the same thing using EOR, but the modification to the checksum depends both the data and its distance to the end of the checked block. If data which is likely to be edited in a repetitive way over many pages is stored at a fixed distance to the ''end'' of the checksum block then the checksum delta can be pre-computed and applied directly without recalculation.<br />
<br />
At least two ideas have been discussed so far:<br />
#checksum payload, then variable-length header content, then fixed-length header<br />
#checksum different components separately and EOR them together in an order-insensitive way, or EOR them with length-agnostic perturbations which preserve the useful error-detection features of a CRC.<br />
<br />
Note that some CRC libraries and accelerators will have overheads that restrict their ability to accumulate data in a random order. They're likely to prefer well-aligned data and long runs of conventionally-ordered data. An ideal solution wouldn't interfere with their operation unnecessarily. --[[User:Gumboot|Gumboot]] 12:14, 4 June 2010 (UTC)<br />
:I guess we should figure out what fields people would want to change cheaply. The lacing, for example, isn't going to get changed without changing the data. I think the obvious cases include the DTS (among other things) and that's currently a variable length field. --[[User:Gmaxwell|Gmaxwell]] 15:06, 4 June 2010 (UTC)<br />
::All I had in mind was the stream ID. In fact, perhaps making it easily editable would be preferable to making it large enough that it rarely needs to be changed.<br />
::Of course this is much easier for changing fields from one constant to another. If various bits change in different ways from page to page then you need a larger table of twiddles to mash into the CRC.<br />
::If it's still a desirable feature, then you can use a set of tables to edit each bit in the relevant field, or some collection of those tables representing the adjustment for various distances from the end of the checksum, and the only requirement would be that the possible distances can be constrained. --[[User:Gumboot|Gumboot]] 22:35, 4 June 2010 (UTC)</div>Gumboothttps://wiki.xiph.org/index.php?title=Talk:TransOgg_Page&diff=12224Talk:TransOgg Page2010-06-04T12:16:17Z<p>Gumboot: /* Arrange checksum order of essential data for fast page edits */ -> /* Arrange checksum order for fast page edits of essential data */ does that make more sense?</p>
<hr />
<div>==Checksum==<br />
I would recommend changing the checksum polynomial.<br />
<br />
For the range of page sizes possible in transogg the CRC-32C (Castagnoli) polynomial offers superior error detection ability over the 802.3 CRC32 that we currently have specified. This polynomial is also used by SCTP and iSCSI, so I could wave my arms and suggest that it might be more likely to get hardware assistance (ethernet CRC is usually done on the adaptor, but the SCTP and iSCSI crc can't be easily offloaded) ... but no armwaving is required: i7 has an instruction for the Castagnoli polynomial. There are superior polys to the iSCSI one, at least for some sizes relevant to us[http://www.ece.cmu.edu/~koopman/networks/dsn02/dsn02_koopman.pdf], but they lack obvious prospects of hardware assistance. <br />
<br />
Upsides to switching to Castagnoli CRC:<br />
* Faster CRC on some hardware<br />
* Increased error detection <br />
<br />
Upsides to switching to another improved CRC:<br />
* (Possibly) Increased error detection over Castagnoli<br />
<br />
Upsides to staying with current CRC:<br />
* Decreased implementation size and complexity for something also supporting the ogg format<br />
<br />
...though supporting multiple generator polynomials in a typical software implementation isn't hard.<br />
--[[User:Gmaxwell|Gmaxwell]] 06:56, 29 May 2010 (UTC)<br />
<br />
== Arrange checksum order for fast page edits of essential data ==<br />
<br />
IP allows fast editing of packets by using a checksum that isn't order-sensitive, so you can subtract the old value and add the new value of any given field directly to the checksum without having to re-sum the whole packet. CRC allows the same thing using EOR, but the modification to the checksum depends both the data and its distance to the end of the checked block. If data which is likely to be edited in a repetitive way over many pages is stored at a fixed distance to the ''end'' of the checksum block then the checksum delta can be pre-computed and applied directly without recalculation.<br />
<br />
At least two ideas have been discussed so far:<br />
#checksum payload, then variable-length header content, then fixed-length header<br />
#checksum different components separately and EOR them together in an order-insensitive way, or EOR them with length-agnostic perturbations which preserve the useful error-detection features of a CRC.<br />
<br />
Note that some CRC libraries and accelerators will have overheads that restrict their ability to accumulate data in a random order. They're likely to prefer well-aligned data and long runs of conventionally-ordered data. An ideal solution wouldn't interfere with their operation unnecessarily. --[[User:Gumboot|Gumboot]] 12:14, 4 June 2010 (UTC)</div>Gumboothttps://wiki.xiph.org/index.php?title=Talk:TransOgg_Page&diff=12223Talk:TransOgg Page2010-06-04T12:14:38Z<p>Gumboot: /* Arrange checksum order of essential data for fast page edits */ new section</p>
<hr />
<div>==Checksum==<br />
I would recommend changing the checksum polynomial.<br />
<br />
For the range of page sizes possible in transogg the CRC-32C (Castagnoli) polynomial offers superior error detection ability over the 802.3 CRC32 that we currently have specified. This polynomial is also used by SCTP and iSCSI, so I could wave my arms and suggest that it might be more likely to get hardware assistance (ethernet CRC is usually done on the adaptor, but the SCTP and iSCSI crc can't be easily offloaded) ... but no armwaving is required: i7 has an instruction for the Castagnoli polynomial. There are superior polys to the iSCSI one, at least for some sizes relevant to us[http://www.ece.cmu.edu/~koopman/networks/dsn02/dsn02_koopman.pdf], but they lack obvious prospects of hardware assistance. <br />
<br />
Upsides to switching to Castagnoli CRC:<br />
* Faster CRC on some hardware<br />
* Increased error detection <br />
<br />
Upsides to switching to another improved CRC:<br />
* (Possibly) Increased error detection over Castagnoli<br />
<br />
Upsides to staying with current CRC:<br />
* Decreased implementation size and complexity for something also supporting the ogg format<br />
<br />
...though supporting multiple generator polynomials in a typical software implementation isn't hard.<br />
--[[User:Gmaxwell|Gmaxwell]] 06:56, 29 May 2010 (UTC)<br />
<br />
== Arrange checksum order of essential data for fast page edits ==<br />
<br />
IP allows fast editing of packets by using a checksum that isn't order-sensitive, so you can subtract the old value and add the new value of any given field directly to the checksum without having to re-sum the whole packet. CRC allows the same thing using EOR, but the modification to the checksum depends both the data and its distance to the end of the checked block. If data which is likely to be edited in a repetitive way over many pages is stored at a fixed distance to the ''end'' of the checksum block then the checksum delta can be pre-computed and applied directly without recalculation.<br />
<br />
At least two ideas have been discussed so far:<br />
#checksum payload, then variable-length header content, then fixed-length header<br />
#checksum different components separately and EOR them together in an order-insensitive way, or EOR them with length-agnostic perturbations which preserve the useful error-detection features of a CRC.<br />
<br />
Note that some CRC libraries and accelerators will have overheads that restrict their ability to accumulate data in a random order. They're likely to prefer well-aligned data and long runs of conventionally-ordered data. An ideal solution wouldn't interfere with their operation unnecessarily. --[[User:Gumboot|Gumboot]] 12:14, 4 June 2010 (UTC)</div>Gumboothttps://wiki.xiph.org/index.php?title=TheoraSoftwarePlayers&diff=10489TheoraSoftwarePlayers2009-08-12T22:22:14Z<p>Gumboot: Update xine home page.</p>
<hr />
<div>== Multi-platform ==<br />
* [http://www.videolan.org/vlc/ VLC Media Player]: Open Source media player and streaming server that support virtually every video and audio format<br />
* [https://helixcommunity.org/projects/xiph/ Xiph Plugins for Real Player/Producer]<br />
* Quicktime components for [http://qtcomponents.sourceforge.net/ Quicktime 6] and [http://www.xiph.org/quicktime/ Quicktime 7] – QuickTime and Macintosh OS X plug-ins<br />
* [http://www.mplayerhq.hu/ Mplayer]: Open Source video player<br />
* [http://www.coreplayer.com/ CorePlayer]: A multimedia platform for mobile and desktop computer systems<br />
* [http://www.flumotion.net/cortado/ Cortado]: Java applet playing ogg/theora/vorbis<br />
* [http://www.mozilla.org/developer/#builds Firefox 3.5]: Open Source web browser<br />
* [http://www.google.com/chrome Chrome beta]: Web browser<br />
* [http://dev.opera.com/articles/view/a-call-for-video-on-the-web-opera-vid/ Opera 9.52 Experimental build]: Web browser<br />
* Safari 3.1 and later: Web browser if the [http://xiph.org/quicktime/ XiphQT] components are installed<br />
<br />
== Windows ==<br />
* [http://www.xiph.org/dshow/ DirectShow filter]: Adds support for Ogg Vorbis, Ogg Speex, Ogg Theora, Ogg FLAC, and native FLAC to any DirectShow-compliant player such as Windows Media Player and BSPlayer<br />
* [http://www.visonair.tv/player.php Visonair.tv Player]: Freeware player - Plays Ogg Vorbis and Theora streams<br />
<br />
== Linux/BSD ==<br />
* [http://player.helixcommunity.org Helix Player] - an open source media player for Linux, Solaris, and Symbian based on the [http://helix-client.helixcommunity.org Helix DNA Client] media engine.<br />
* [http://www.gnomefiles.org/app.php?soft_id=64 Totem] - a Free Software (GPL-licensed) media player based on [http://xinehq.de xine] or [http://gstreamer.freedesktop.org GStreamer] media engine.<br />
* [http://www.xine-project.org/home Xine]: a Free Software (GPL-licensed) media player, complete with its own media engine and a long list of supported formats.<br />
<br />
== Mac OS X ==<br />
<br />
* [http://www.xine-project.org/home Xine]: a Free Software (GPL-licensed) media player, complete with its own media engine and a long list of supported formats. Supports Darwin/MacOS X (ppc) via the fink project.<br />
<br />
== See also == <br />
{{Template:Theora}}<br />
<br />
[[Category:Theora]]</div>Gumboothttps://wiki.xiph.org/index.php?title=User_talk:Silvia&diff=4068User talk:Silvia2005-12-18T14:11:26Z<p>Gumboot: revert spam</p>
<hr />
<div></div>Gumboothttps://wiki.xiph.org/index.php?title=User:Jmspeex&diff=4066User:Jmspeex2005-12-18T14:06:47Z<p>Gumboot: revert spam</p>
<hr />
<div>Author of Speex<br />
<br />
[http://people.xiph.org/~jm/ Home page]</div>Gumboothttps://wiki.xiph.org/index.php?title=Http://www.xiph.org/vorbis/doc/Vorbis_I_spec.html&diff=4062Http://www.xiph.org/vorbis/doc/Vorbis I spec.html2005-12-18T14:04:09Z<p>Gumboot: {{delete}}</p>
<hr />
<div>{{delete}}</div>Gumboothttps://wiki.xiph.org/index.php?title=Theora_Hardware&diff=4060Theora Hardware2005-12-18T14:00:58Z<p>Gumboot: revert to '{{delete}}'</p>
<hr />
<div>{{delete}}</div>Gumboothttps://wiki.xiph.org/index.php?title=Main_Page&diff=2249Main Page2005-12-07T20:38:25Z<p>Gumboot: revert spam</p>
<hr />
<div>= Projects/Formats =<br />
<br />
In an effort to bring open-source ideals to the world of multimedia the [[Xiph.org Foundation]] develops a multitude of amazing products. <br />
<br />
== Container Formats ==<br />
<br />
* [[Ogg]]: Media container. This is our native format and the recommeded container for Xiph codecs.<br />
* [[Ogg Skeleton]]: Skeleton information on all logical content bitstreams in Ogg.<br />
<br />
* [[SpeexRTP]]: RTP payload format for voice<br />
* [[VorbisRTP]]: RTP payload format for general audio<br />
* [[TheoraRTP]]: RTP payload format for video<br />
* [[XSPF]]: XML playlist format<br />
<br />
== Codecs ==<br />
<br />
* '''Compressed Codecs:'''<br />
** [[Vorbis]]: Audio codec with a [[Tremor|fixed point decoder]]<br />
** [[Theora]]: Video codec<br />
** [[FLAC]]: Free Lossless Audio Codec<br />
** [[Speex]]: Speech codec<br />
** [[OggMNG]]: A mapping for encapsulating the MNG animation format in Ogg<br />
* '''[[RawCodecs|Uncompressed Codecs]]:'''<br />
** Audio:<br />
*** [[OggPCM]]: Uncompressed PCM audio, primarily as an interchange codec<br />
*** [[OggPCM2]]: An Alternative Uncompressed PCM audio, under active development<br />
*** [[OggPCM3|Humorous PCM format]]: Uncompressed PCM audio - and a lot more!<br />
** Video:<br />
*** [[OggRGB]]: Uncompressed RGB video, primarily as an interchange codec, under active development <br />
*** [[OggYUV]]: Uncompressed YUV video, primarily as an interchange codec, under active development<br />
*** [[OggUVS]]: Uncompressed RGB and YUV video, under active development as an alternative to OggRGB and OggYUV.<br />
** Text & Hyperlinking:<br />
*** [[OggWrit]]: Text phrase codec (e.g. subtitles)<br />
*** [http://annodex.net/TR/draft-pfeiffer-cmml-02.txt CMML]: Continuous Media Markup Language, used for [http://www.annodex.net/ Annodex] and subtitles (xine, vlc, gstreamer, and DirectShow support)<br />
* '''Metadata Codecs:'''<br />
** [[Metadata]]: Arbitrary metadata stream format (vapourware so far)<br />
<br />
== Software for distributing media ==<br />
<br />
* [[Icecast]]: Streaming server<br />
* [[Ices]]: Source client for Icecast servers<br />
* [[IceShare]]: P2P content distribution<br />
<br />
== Other software ==<br />
<br />
* [[OggComponent/VorbisComponent]]: Wrappers to integrate Ogg-Vorbis into MacOsX<br />
<br />
== Demonstrations ==<br />
<br />
Want to hear Xiph in action? These projects are using our codecs, formats, or libraries.<br />
<br />
* [[VorbisStreams]]: Stations streaming with the Vorbis codec<br />
* [[Games that use Vorbis]]: Games using the Vorbis codec for music or sound effects<br />
* [[VorbisHardware]]: Hardware players using the Vorbis codec<br />
* [http://www.tversity.com TVersity Media Server]: A UPNP/AV compliant media server that uses the Ogg Vorbis libraries to transcode audio files to the Ogg Vorbis format.<br />
<br />
== Project management ==<br />
<br />
* [[MonthlyMeeting]]<br />
* [[MailingLists]]<br />
* [[Bounties]]<br />
* [[HyperFish]]<br />
<br />
== Wiki internal ==<br />
* [[Sandbox]]: Testbed for testing editing skills.<br />
* [[Translations]]: What about some translation work</div>Gumboothttps://wiki.xiph.org/index.php?title=XiphWiki:Sandbox&diff=2255XiphWiki:Sandbox2005-12-04T11:54:31Z<p>Gumboot: revert spam</p>
<hr />
<div>= Headline 1 =<br />
== Headline 2 ==<br />
=== Headline 3 ===<br />
=== Headline 4 ===<br />
{| border=2 cellpadding=10<br />
|+ '''Table test'''<br />
| x || 'One' || ''Two2'' || '''Three'''<br />
|-<br />
! what is this<br />
| 'yes' <br />
| ''no'' <br />
! maybe<br />
|-<br />
!<br />
{| border=1 cellpadding =2<br />
|+ for you<br />
| a<br />
| b<br />
| c<br />
|-<br />
| d || e|| f<br />
|}<br />
| 1 || 2 || 3<br />
|}<br />
<br />
This is a good test<br />
<br />
== Headline 5 ==<br />
<br />
* Item 1<br />
* Item 2<br />
* Item 3<br />
<br />
<br />
LoSSSSSSSSSSSSSSSSSSSSSSSSSSSSSStus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.<br />
<br />
Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.<br />
<br />
Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.<br />
<br />
It has been reported that links to ".com" sites don't work: [http://www.vorbis.com/ Vorbis Website]<br />
<br />
== Headline 2 ==<br />
Good goodess, don't you hate wiki spam?</div>Gumboothttps://wiki.xiph.org/index.php?title=Main_Page&diff=2232Main Page2005-12-03T20:11:11Z<p>Gumboot: revert spam</p>
<hr />
<div>= Projects/Formats =<br />
<br />
In an effort to bring open-source ideals to the world of multimedia The Xiph.org Foundation ([[XiphOrg]]) develops a multitude of amazing products. <br />
<br />
== Container Formats ==<br />
<br />
* [[Ogg]]: Media container. This is our native format and the recommeded container for Xiph codecs.<br />
* [[OggSkeleton]]: Skeleton information on all logical content bitstreams in Ogg<br />
<br />
* [[SpeexRTP]]: RTP payload format for voice<br />
* [[VorbisRTP]]: RTP payload format for general audio<br />
* [[TheoraRTP]]: RTP payload format for video<br />
* [[XSPF]]: XML playlist format<br />
<br />
== Codecs ==<br />
* '''Compressed Codecs:'''<br />
** [[Vorbis]]: Audio codec with a [[Tremor|fixed point decoder]]<br />
** [[Theora]]: Video codec<br />
** [[FLAC]]: Free Lossless Audio Codec<br />
** [[Speex]]: Speech codec<br />
** [[OggMNG]]: A mapping for encapsulating the MNG animation format in Ogg<br />
* '''[[RawCodecs|Uncompressed Codecs]]:'''<br />
** Audio:<br />
*** [[OggPCM]]: Uncompressed PCM audio, primarily as an interchange codec<br />
*** [[OggPCM2]]: An Alternative Uncompressed PCM audio, under active development<br />
*** [[OggPCM3|Humorous PCM format]]: Uncompressed PCM audio - and a lot more!<br />
** Video:<br />
*** [[OggRGB]]: Uncompressed RGB video, primarily as an interchange codec, under active development <br />
*** [[OggYUV]]: Uncompressed YUV video, primarily as an interchange codec, under active development<br />
*** [[OggUVS]]: Uncompressed RGB and YUV video, under active development as an alternative to OggRGB and OggYUV.<br />
** Text & Hyperlinking:<br />
*** [[OggWrit]]: Text phrase codec (e.g. subtitles)<br />
*** [http://annodex.net/TR/draft-pfeiffer-cmml-02.txt CMML]: Continuous Media Markup Language, used for [http://www.annodex.net/ Annodex] and subtitles (xine, vlc, gstreamer, and DirectShow support)<br />
* '''Metadata Codecs:'''<br />
** [[Metadata]]: Arbitrary metadata stream format (vapourware so far)<br />
<br />
== Software for distributing media ==<br />
<br />
* [[Icecast]]: Streaming server<br />
* [[Ices]]: Source client for Icecast servers<br />
* [[IceShare]]: P2P content distribution<br />
<br />
== Other software ==<br />
<br />
* [[OggComponent/VorbisComponent]]: Wrappers to integrate Ogg-Vorbis into MacOsX<br />
<br />
= Demonstrations =<br />
<br />
Want to hear Xiph in action? These projects are using our codecs, formats, or libraries.<br />
<br />
* [[VorbisStreams]]: Stations streaming with the Vorbis codec<br />
* [[Games that use Vorbis]]: Games using the Vorbis codec for music or sound effects<br />
* [[VorbisHardware]]: Hardware players using the Vorbis codec<br />
* [http://www.tversity.com TVersity Media Server]: A UPNP/AV compliant media server that uses the Ogg Vorbis libraries to transcode audio files to the Ogg Vorbis format.<br />
<br />
= Project management =<br />
<br />
* [[MonthlyMeeting]]<br />
* [[MailingLists]]<br />
* [[Bounties]]<br />
* [[HyperFish]]<br />
<br />
= Wiki internal =<br />
* [[Sandbox]]: Testbed for testing editing skills.<br />
* [[Translations]]: What about some translation work</div>Gumboothttps://wiki.xiph.org/index.php?title=Help:Contents&diff=3168Help:Contents2005-12-03T20:11:05Z<p>Gumboot: revert spam</p>
<hr />
<div></div>Gumboothttps://wiki.xiph.org/index.php?title=User:Erikd&diff=3226User:Erikd2005-12-03T20:10:59Z<p>Gumboot: revert spam</p>
<hr />
<div>I'm the main author and maintainer of libsndfile [[http://www.mega-nerd.com/libsndfile/]].<br />
<br />
I'm hoping to help out on the specification of [[OggPCM]].</div>Gumboothttps://wiki.xiph.org/index.php?title=Current_events&diff=2241Current events2005-12-03T20:10:45Z<p>Gumboot: revert spam</p>
<hr />
<div>__NOTOC__<br />
What's happening in the world of Xiph.org? See [[Wikipedia:Current events]] for an example of what this should become like.<br />
<br />
== 2005-10-15 ==<br />
<br />
[http://free.wave.online.fr/ FreeWaveOnline] is a new Web-radio dedicated to Free Music. It use [[XSPF]] playlists[http://free.wave.online.fr/xmediaplayer/playlists/empty_playlist.xml]. This radio is in french but music is internationnal ;)<br />
<br />
== 2005-06-27 ==<br />
<br />
[[Vorbis]] 1.1.1 released. Some bug and documentation fixes, but no new <br />
encoder modes. [http://lists.xiph.org/pipermail/vorbis-dev/2005-June/018105.html]<br />
<br />
== 2005-06-11 ==<br />
<br />
[[Speex]] 1.1.10 released.<br />
<br />
== 2005-02-05 ==<br />
<br />
[[FLAC]] 1.1.2 released.<br />
<br />
== 2004-12-21 ==<br />
<br />
[[Icecast]] 2.2.0 released.<br />
<br />
== 2004-12-15 ==<br />
<br />
[[Theora|libtheora]] 1.0 alpha 4 released. [http://www.theora.org/]</div>Gumboothttps://wiki.xiph.org/index.php?title=XiphWiki:Community_Portal&diff=3029XiphWiki:Community Portal2005-12-03T20:10:37Z<p>Gumboot: revert spam</p>
<hr />
<div>There's nothing much really here, albeit the community can be found both at the [http://www.hydrogenaudio.org/forums/ Hydrogen Audio forums] and at the [[Wikipedia:Internet Relay Chat|IRC]] channels on [http://freenode.net/ Freenode].</div>Gumboothttps://wiki.xiph.org/index.php?title=Main_Page&diff=2217Main Page2005-12-03T01:34:01Z<p>Gumboot: revert spam</p>
<hr />
<div>= Projects/Formats =<br />
<br />
In an effort to bring open-source ideals to the world of multimedia The Xiph.org Foundation ([[XiphOrg]]) develops a multitude of amazing products. <br />
<br />
== Container Formats ==<br />
<br />
* [[Ogg]]: Media container. This is our native format and the recommeded container for Xiph codecs.<br />
* [[OggSkeleton]]: Skeleton information on all logical content bitstreams in Ogg<br />
<br />
* [[SpeexRTP]]: RTP payload format for voice<br />
* [[VorbisRTP]]: RTP payload format for general audio<br />
* [[TheoraRTP]]: RTP payload format for video<br />
* [[XSPF]]: XML playlist format<br />
<br />
== Codecs ==<br />
* '''Compressed Codecs:'''<br />
** [[Vorbis]]: Audio codec with a [[Tremor|fixed point decoder]]<br />
** [[Theora]]: Video codec<br />
** [[FLAC]]: Free Lossless Audio Codec<br />
** [[Speex]]: Speech codec<br />
** [[OggMNG]]: A mapping for encapsulating the MNG animation format in Ogg<br />
* '''[[RawCodecs|Uncompressed Codecs]]:'''<br />
** Audio:<br />
*** [[OggPCM]]: Uncompressed PCM audio, primarily as an interchange codec<br />
*** [[OggPCM2]]: An Alternative Uncompressed PCM audio, under active development<br />
*** [[OggPCM3|Humorous PCM format]]: Uncompressed PCM audio - and a lot more!<br />
** Video:<br />
*** [[OggRGB]]: Uncompressed RGB video, primarily as an interchange codec, under active development <br />
*** [[OggYUV]]: Uncompressed YUV video, primarily as an interchange codec, under active development<br />
*** [[OggUVS]]: Uncompressed RGB and YUV video, under active development as an alternative to OggRGB and OggYUV.<br />
** Text & Hyperlinking:<br />
*** [[OggWrit]]: Text phrase codec (e.g. subtitles)<br />
*** [http://annodex.net/TR/draft-pfeiffer-cmml-02.txt CMML]: Continuous Media Markup Language, used for [http://www.annodex.net/ Annodex] and subtitles (xine, vlc, gstreamer, and DirectShow support)<br />
* '''Metadata Codecs:'''<br />
** [[Metadata]]: Arbitrary metadata stream format (vapourware so far)<br />
<br />
== Software for distributing media ==<br />
<br />
* [[Icecast]]: Streaming server<br />
* [[Ices]]: Source client for Icecast servers<br />
* [[IceShare]]: P2P content distribution<br />
<br />
== Other software ==<br />
<br />
* [[OggComponent/VorbisComponent]]: Wrappers to integrate Ogg-Vorbis into MacOsX<br />
<br />
= Demonstrations =<br />
<br />
Want to hear Xiph in action? These projects are using our codecs, formats, or libraries.<br />
<br />
* [[VorbisStreams]]: Stations streaming with the Vorbis codec<br />
* [[Games that use Vorbis]]: Games using the Vorbis codec for music or sound effects<br />
* [[VorbisHardware]]: Hardware players using the Vorbis codec<br />
* [http://www.tversity.com TVersity Media Server]: A UPNP/AV compliant media server that uses the Ogg Vorbis libraries to transcode audio files to the Ogg Vorbis format.<br />
<br />
= Project management =<br />
<br />
* [[MonthlyMeeting]]<br />
* [[MailingLists]]<br />
* [[Bounties]]<br />
* [[HyperFish]]<br />
<br />
= Wiki internal =<br />
* [[Sandbox]]: Testbed for testing editing skills.<br />
* [[Translations]]: What about some translation work</div>Gumboothttps://wiki.xiph.org/index.php?title=PortablePlayers&diff=2204PortablePlayers2005-12-01T09:45:35Z<p>Gumboot: revert spam</p>
<hr />
<div>Here you can find all mobile players known to support Ogg [[Vorbis]]. Some do also play FLAC (please add information).<br />
<br />
== Flash Memory Storage ==<br />
<br />
* [http://www.netonnet.se/item.asp?iid=61510 Avant] MP-8256, MP-8512, MP-81000<br />
:Looks like another whitebox label (?) No official website found yet, but three models are offered in shops: MP-8256 with 256MB memory, MP-8512 (512MB) and MP-81000 (1GB). Plays not only Ogg Vorbis, but [[MP3]], [[WMA]] and even JPEG via colour display. <br />
<br />
* [http://enox.co.kr/2004/eng/ ENOX] EMX-830, EMX-900, EMX-530<br />
:'The lightest and the smallest one among AAA type MP3 players.' Supports MP3, WMA, ASF, WAV, and Ogg Vorbis, has FM tuner, line-in and mic with direct MP3 encoding. Comes with 128/256/512/1024MB flash memory and USB 2.0 interface. The EMX-900 has up to 1 GB storage and supports the same file formats. <br />
<br />
* [http://www.ez-av.com/eng/ EZAV's] EMP-600, EMP-500, EMP-400<br />
:The EMP-500 is a very light player, comes with 256/512/1024MB storage and supports MP3, WMA, and Ogg Vorbis. The EMP-400 has 256MB storage.<br />
<br />
* [http://www.gp2x.com/ Gamepark Holdings] GP2X<br />
:Linux-based handheld audio/video/game player, supports MP3 and Ogg Vorbis. Uses SD cards for storage (sold seperately).<br />
<br />
* [http://eng.iaudio.com/ iAudio] U2, G3, 5, G2<br />
:The iAudio U2 is a small flash-based player (256MB/512MB/1GB) and supports Vorbis. Early U2 releases required a firmware upgrade for Vorbis support; as of September 2005 this support was included in the retail version. The iAudio G3 and iAudio 5 offer up to 2GB, and support Ogg Vorbis out-of-the-box. The G2 has storage from 256 MB up to 1 GB and supports the same formats. All will talk to Linux or Mac (but included s/w is Windows only).<br />
<br />
* [http://www.ibead.co.kr/coding/eng/ i-BEAD] 170, 400, 600<br />
:The i-BEAD 170 & 400 models are small, light flash-based players with built in Lithium-Polymer batteries. They also have OLED displays, and FM & line-in recording. Both are available in 256MB/512MB/1GB and both support Ogg Vorbis after a firmware upgrade. The i-BEAD 600 has up to 2 GB storage and is very small and supports Ogg Vorbis out of the box. PLEASE NOTE: Ogg Vorbis files encoded using pre-1.0 versions of the encoder will not work with these players.<br />
<br />
* [http://www.iops.co.kr/enghome/index.html Iops] MFP-312, MFP-325, MFP-350<br />
:Iops offers the MFP-300 series player with 128/256/512MB/1GB internal flash memory. They offer voice and FM radio recording whilst maintaining a lightweight portable size.<br />
<br />
* [http://www.iriver.com/ iRiver's] iFP-3xx, iFP-5xx, iFP-7xx, iFP-8xx, iFP-9xx, iFP-10xx, iFP-11xx, T10, T20, U10<br />
:iRiver has a huge line of flash-based players with various memory sizes (128MB to 1GB). Some of these players may need an updated firmware in order to play Ogg Vorbis files, see the [http://www.iriver.com/support/download.asp support download page] for that. Note -- on older players, only certain bitrates are supported, various problems are reported including reboots, silence and random noise when a VBR Vorbis passes outside the limit (96-225 Kbps). Newer players don't have this limitation. However, please be alerted that many of the newer players use weird protocols like MTP so they only work with Windows.<br />
<br />
* [http://www.jensofsweden.com/ Jens Of Sweden's] MP-120, MP-130, MP-400, MP-450<br />
:The MP-130 is a portable player with flash memory in 128/256/512MB sizes. This appears to be a rebranded Iops player. The MP-400 is a tiny machine with lots of features (line in, mic, fm radio, usb 2.0). With the updated 4.1 firmware it supports Ogg Vorbis files encoded with libvorbis version 1.0rc2 or later. When trying to play files encoded with earlier versions it freezes on playback, requiring an USB connect or reset button pressed (through a tiny hole) to wake up again. The MP-120, a 1Gb flash player, supports Ogg-Vorbis with a firmware upgrade since March 2005. MP-120 still doesn't play old Ogg Vorbis files, but they don't make it freeze up. The MP-450 is basically a MP-400 with color display.<br />
<br />
* [http://www.jnc-digital.com/Eng/ JNC's] SSF-2002, SSF-2005<br />
:These are flash-based players with 256 MB respectively 512 MB storage capacity. They have the usual FM radio which can be recorded in addition to voice. They also have a 1,9" color display.<br />
<br />
* [http://www.lexar.com/mp3/index.html Lexar's] LDP-800<br />
:Available from 03/2005 the LDP-800 is offering MP3, WMA and Ogg Vorbis Support with 256/512MB storage. It has a digital out, FM receiver and transmitter, can record from FM, mic and line-in and has a SD-card slot. Includes Sennheiser earbuds. Update: A telephoned sales representative informed on 2005-04-15 that this player would be available sometime in June. Update again: A sales representative telephoned on 2005-06-20 again stated that the player would be available sometime in June. However, a sales representitave at [http://www.ecost.com/ eCOST], an online store carrying the LDP-800, stated that their availability date is now 2005-07-15. Lexar now seem to have dropped this product. See discussion.<br />
<br />
* [http://www.maxfield.de/ Maxfield's] Max-Diamond, Max-Movie, Max-Diablo<br />
: It's not yet on the homepage, but the Max-Diamond will be released in 03/2005 and supports MP3, Ogg Vorbis and WMA (DRM). It has 512MB flash memory and can record from FM radio. The Max-Movie has 1GB storage and supports DivX, MP3 WMA (DRM) and Ogg Vorbis. It also has FM radio and a display with 260.000 colors. The Max-Diablo supports the same audio formats, but can also display pictures and videos on its small OLED (4096 colors). It has 1GB storage.<br />
<br />
* [http://www.mbird.co.kr/ M-bird's] XT-22S<br />
: Available in 256MB/512MB/1GB sizes. USB 2.0. Supports Ogg Vorbis (although it doesn't seem to view tag info, will probably be fixed in future firmwares (?)), but also MP3 and WMA. It has small 200 mW built-in speaker. Inverted display with the ability to choose the foreground colour in 125 steps. Other features include FM-radio, voice recorder (built-in mic), line-in, alarm, and more.<br />
<br />
* [http://mpeye.net/ MPeye] TS-400<br />
:a flash player which comes in 128MB/256MB/512MB/1GB sizes, has a FM-receiver, colour display and a voice recorder. <br />
<br />
* [http://www.muzio.co.kr/ Muzio's] JM200, JM250, JM300<br />
:Another Korean manufacturer jumps in and offers small flash-based players with 128MB up to 1GB storage capacities. They support the usual formats MP3/WMA/Ogg Vorbis, can record voice, receive FM radio.<br />
<br />
* [http://www.neurosaudio.com/ Neuros'] Neuros II<br />
:The Neuros II can be used as a stand-alone flash-player. You can later buy an HDD "backpack" from 20 to 80 gigs in size and switch the backpacks as you please. This player now has a [http://open.neurosaudio.com/ free software (open-source) firmware].<br />
<br />
* [http://www.pretec.com/OnlineSales/SSD/iDisk/Allegro/Allegro.htm Pretec's] Allegro<br />
:The player supports MP3, WMA and Ogg Vorbis formats, uses USB Flash Drives for storage, has a 128x64 pixel blue screen with file info in 5 languages, 6 preset sound stages, one user defined graphic equalizer, low power consumption.<br />
<br />
* [http://eng.qoolqee.com/ Qoolqee's] K7<br />
:This is an interesting mix of a flash-based MP3 player and an organizer: the player has 512/1024 MB storage and contact and calendar functions and can sync with Outlook. It supports MP3, WMA and Ogg Vorbis, has FM radio and connectors for two headphones.<br />
<br />
* [http://www.samsung.com/Products/ Samsung] / [http://www.yepp.co.kr/ Yepp] (product label), YP-T6, YP-T7, YP-C1, YP-F1, YP-MT6, YP-53, YP-U1<br />
:The YP-T6 is an incredibly small flash player with 128/256/512/1024 MB storage, has a mic and FM radio and supports MP3, WMA (DRM) and Ogg Vorbis. The YP-T7 has either 512MB or 1GB capacity and supports the same audio formats, which also applies to the YP-F1. It can display JPEGs on its color display. The YP-C1 has similar specs, including Ogg support; at the time of writing, it seems to be readily available only in Korea and China. The YP-53, a small flash player with 128/256/512/1024 MB storage, mic, USB 2.0 and FM radio, supports MP3, WAV, WMA(DRM), Ogg Vorbis(-q >= 0) with Firmware 1.200. The YP-U1 is a small (2,38 x 8,78 x 1,35 cm, ~32g) flash player with 128/256/512/1024/2048 MB storage. The player has a LCD b/w display and an integrated accumulator that is charged via USB. It supports USB2.0 and has an integrated USB-plug that can be flipped in and out, so no cable or adapter is needed. Besides OGG the YP-U1 supports MP3, ASF and WMA (and directory structures). <br />
<br />
:*[[Talk:PortablePlayers#Samsung's Yepp Ogg Vorbis support|There have been reports that the Ogg Vorbis support in the YP-T6 is buggy.]]<br />
<br />
* [http://www.supportplus.cn/ SupportPlus'] SP-Advance<br />
:Found this player in the local supermarket, the website seems to be a joke. The player is very small, has a 1 inch color LCD and 1 GB of storage. Supports audio and video incl. Ogg Vorbis.<br />
<br />
* [http://www.teac.com/ TEAC's] MP-400<br />
:The MP-400 is a flsh-player with either 512/1024MB storage. It supports MP3, WMA, Ogg Vorbis and MPEG-4 video.<br />
<br />
* [http://www.trekstor.de/ TrekStor's] iBeat fresh, iBeat organix, iBeat cube, iBeat ice, iBeat vision<br />
:The iBeat fresh comes with 256/512 MB storage has a 64K color display and the usual features. The iBeat organix is supposed to get a firmware upgrade and comes with 256/512/1024 MB flash memory. The iBeat cube is a very small player with the usual features. The iBeat ice has a sharp OLED display. The iBeat vision has a large display that can be used to watch movies. It comes in sizes from 256MB to 2GB.<br />
<br />
* [http://www.wigobyte.com/ Wigo's] CVM-101, CVM-103, CVM-300, CVS-100<br />
:Korean players with slick design, comes in 128/256/512/1024 MB depending on models. Support MP3/WMA/Ogg, FM receiver, voice recorder. Note: Ogg bitrates supported may be limited, check the manufacturer's specification for each device for details.<br />
<br />
* [http://www.xcent.co.kr Xcent's] XT100<br />
:This player is sold in the U.K. and comes with 256/512MB. It supports MP3, WMA, Ogg Vorbis and has FM radio and voice recording. It also works under Linux (kernel 2.4 upwards) and FreeBSD 5.3 (recognised as a removable mass storage device).<br />
<br />
== Harddisk Storage ==<br />
<br />
* [http://www.airlinktek.com/ AL Tech's] MG-25, MG-35, MG350HD<br />
:The Mediagate MG-25 is a portable HDD that supports also media playback. It uses a 2,5" disk and USB2.0 to connect, and supports MPEG-1/-2/-4, DivX, Xvid, MP3, Ogg Vorbis, JPG. It can upsample to HDTV, has composite, component and s-video outs, stereo and a digital out. Remote control is included. The MG-35 uses a 3,5" HDD instead, supports WMA and ethernet. The MG350HD uses a 3,5" HDD as well and supports HDTV.<br />
<br />
* [http://www.boghe.com/products/audio/vip20.htm Boghe] Vip20<br />
:The Vip20 seems to be similar to the iBeat 500 from TrekStor and Xclef HD-800. It has the same features: MP3, WMA, WAV, Ogg Vorbis decoding plus 20 GB storage.<br />
<br />
* [http://www.commodore.net/ Commodore's] eVic<br />
:The eVic has 20GB storage and plays WMA (incl. DRM), MP3 and Ogg Vorbis. It can record voice and music, and has USB host functionality.<br />
<br />
* [http://www.digmind.com/ Digital Mind Corporation's] DMC 8280<br />
:The [http://www.digmind.com/store/index_8280.html DMC 8280] has 20 GB or 30 GB storage, plays Ogg Vorbis, MP3 and WMA. Standard feature set; this player does not excel in any area but price. USB mass storage compliant -- you can put songs on it from non-Windows computers, but full indexing of the songs for reference by artist etc. requires Windows.<br />
<br />
* [http://www.freecom.com/ Freecom's] MediaPlayer-3, Network MediaPlayer-35 Drive-In<br />
:The MediaPlayer-3 is again sort of an external HDD that can play media without a PC. It supports DivX, MP3, MPEG-4, AVI, WMA, ASF and Ogg Vorbis. The product with the complicated name Network MediaPlayer-35 Drive-In is an enhanced version of the MediaPlayer-3 -- it has an additional network interface and supports an internal 3,5" drive. The ethernet port can be used to read media from the network, but cannot be used as network attached storage.<br />
<br />
* [http://www.godot.com.tw/ GoDot] M8170, M8270, M8370, M8470, M8570<br />
:GoDot's HD players have capacity ranging from 2.2gb to 20gb. Each model is very different. They support Ogg Vorbis, MP3 and WMA (some models support DRM).<br />
<br />
* [http://www.hama.de/portal?lid=2 Hama's] VSV-20/VSV-40<br />
:The VSV-20/VSV-40 has the usual mobile MP3 HDD player size and can read/write from its 16in1 memory card reader and 20 GB or 40 GB internal HDD. But it can do more than audio (MP3, WMA, Ogg Vorbis, AAC). It supports image (JPEG) and video (MPEG-1/-4) playback on the 2" display and on a connected TV. It even includes a remote control. Beware: Hama has suspended OggVorbis support. However, there is a Firmware update promised to reestablish OggVorbis. If you plan to buy a device check the [http://www.hama.de/service/download/firmware/index.hsp Firmware download page] or better [http://www.hama.de/portal/pageId*2276/action*3499 ask them] about the current status of OggVorbis support.<br />
<br />
* [http://eng.iaudio.com/ iAudio] M3, M5, X5, A2<br />
:The iAudio M3 is a portable harddisk player with either 20 or 40 GB of storage. It has a built-in FM radio and mic. It supports MP3, WMA, Ogg Vorbis and WAV and even FLAC with the newest firmware upgrade. See this [http://gear.ign.com/articles/522/522090p1.html IGN article] for more info. The M5 has 20 GB storage and supports the same formats. The X5 is designed similar (storage sizes of 20GB, 30GB, 60GB) and can play MPEG-4 videos. It has a 1.8 inch LCD with 260,000 colors and USB OTG (On-The-Go) feature. The A2 is released in November 2005 and is a widescreen mobile video player. It has a 480 x 272 pixel screen and supports the above metioned set of audio, video and image formats.<br />
<br />
* [http://www.ivmm.com/innoax/products_innopod.html InnoAX's] InnoPod<br />
:This is a iPod mini clone, that supports MP3, WMA, WAV and Ogg Vorbis. It supports recording from line-in and mic, has a 4 GB harddrive and USB2.0.<br />
<br />
* [http://www.iomega.com/ Iomega's] ScreenPlay Pro<br />
:Iomega is finally also jumping on the bandwaggon and offers external HDDs with multimedia-playback. The larger version ScreenPlay Pro supports the usual audio and video codecs including Ogg Vorbis.<br />
<br />
* [http://www.iriver.com/ iRiver's] iHP-1xx, H1xx, H2xx, H3xx, iGP-100<br />
:iRiver has also a number of harddisk based items that play back Ogg Vorbis. Older models like the [http://www.iriver.com/product/info.asp?p_name=iHP-100 iHP-100] and the [http://www.iriver.co.kr/product/info.asp?p_group=iHP&amp;p_name=iHP-115 iHP-115] come in 10 and 15 GB sizes and need a firmware update (see the [http://www.iriver.com/support/download.asp support downloads] for that). The [http://www.iriver.com/product/info.asp?p_name=iHP-120 iHP-120], a 20GB portable player, and the [http://www.iriver.com/product/info.asp?p_name=iHP-140 iHP-140], a 40GB version, support Vorbis playback out of the box. Read reviews here: [http://gear.ign.com/articles/435/435472p1.html IGN on iHP-100], [http://gear.ign.com/articles/457/457818p1.html IGN on iHP-120]. The [http://www.iriveramerica.com/products/iGP-100.asp iGP-100], a 1.5Gb portable player, supports Vorbis, according to the FAQ, though no firmware upgrade appears to be required. The new line of harddisk players [http://www.iriver.com/product/info.asp?p_name=H140H110 H120, H140] come in 10 to 40 GB sizes. There is also a product line with USB host function and colour display that supports 32-500kbs: [http://www.iriver.com/product/info.asp?p_name=H340 H320, H340].<br />
<br />
* [http://www.jetaudio.com/products/tvix/ JetAudio's] [http://www.tvix.co.kr/eng/ Dvico's] TViX<br />
:This is a rather unique device. JetAudio calls it a multimedia jukebox, music tank, photo album and last but not least a portable storage. It is bigger than usual portable devices, but has also a lot more options. It can connect to the PC (USB 2.0), TV (S-Video, Composite), stereos and 5.1 surround systems (Coaxial/Optical) and comes with a remote control. Supported video formats are DVD (MPEG-2), VCD (MPEG-1), DivX, Xvid. Supported Audio formats are MP3, WMA and Ogg Vorbis. It can display JPEG pictures on the TV. It is available without a harddrive, or equipped with harddrive sizes up to 200 GB.<br />
<br />
* [http://www.jnc-digital.com/Eng/ JNC's] SSF-M3, SSF-M5<br />
:The SSF-M3 comes with 20/40GB storage size, whereas the SSF-M5 has only 1.5 GB. Both support voice recording and FM radio. The SSF-M3 is more stylish and very slim and comes with a docking station.<br />
<br />
* [http://www.lge.com/ LG's] Mediagate<br />
:This player is similar to the Modix or TViX. It is a portable USB HDD equipped with a 2,5" drive (size varies). It plays audio (MP3, Ogg Vorbis, WMA), video (MPEG-1/-2, Xvid, DivX) and images (JPEG). It has composite, s-video and component video output and supports progressive scan, audio output is done through a coaxial and stereo plug. The device is bundled with a remote control.<br />
<br />
* [http://www.modix.co.kr/ Modix] HD-3510<br />
:The HD-3510 is similar to the TViX, as it is sort of a portable multi-talent. It can store and playback audio, video and images, and can be used for other files as well. It can decode MPEG-1/-2/-4 including DivX/Xvid, AC3, DTS, MP3, WMA, Ogg Vorbis and JPEG. It uses USB2.0 for data input and has various ouput connectors: anlog stereo and 5.1 out, coaxial digital out, composite, s-video and component video out with progressive scan and HDTV upscaling. The HD-3510 is bundled with a carrying bag and a remote control, but without a 3,5" HDD.<br />
<br />
* [http://mpeye.net/ MPeye's] HT-100, HT-150<br />
:The HT-100 uses a 1,5 GB HDD, decodes MP3, WMA, Ogg Vorbis and supports the usual features. The HT-150 seems to have the same features (maybe a mistake on the website).<br />
<br />
* [http://www.mpio.com/ mpio] HD300, HD200, One<br />
:mpio HD300 is a harddisk player with 20GB and supports WAV/MP3/WMA/Ogg Vorbis. It has FM radio, an alarm clock and supports USB 2.0. The HD200 has 5GB storage capacity, a FM radio which can be recorded and supports the same formats as the HD300. Despite its name the One consist of three components: a player, a HDD and a CD-ROM drive, which can be combined with each other. It supports [[MP3]], [[WMA]], Ogg Vorbis, JPG, BMP and MPEG-4 movies. It has a 1" OLED display and will be available from 05/2005.<br />
<br />
* [http://www.imp3.net/read.php?textid=1529 Muzio's] JM-600<br />
:This player comes with either 2.2 or 4 GB harddrive and supports MP3, WMA, Ogg Vorbis and ASF. It can record voice and has a FM receiver. What sets this player apart is the LCD -- it can show BMPs, JPGs and text. The device can also act as a USB host to support digital cameras.<br />
<br />
* [http://www.macpower.com.tw/ Macpower] Mvisto MV-U2UGS<br />
:The Mvisto is a portable hardware enclosure for 2,5" harddrives. It has video and audio outs and decodes MPEG1/2/Divx/Xvid/JPEG/MP3/WMA/AAC/Ogg Vorbis. It comes with a remote control.<br />
<br />
* [http://www.neurosaudio.com/ Neuros'] Neuros II<br />
:This mobile player comes either with various harddrive sizes up to 80 GB or as 256 MB flash player. The new firmware to support Ogg Vorbis has been developed by the Xiph.org Foundation (see the [http://www.neurosaudio.com/press/news_item.aspx?itemID=80 press release]). Get the newest firmware version at Neuros' [http://www.neurosaudio.com/support/support_updates.asp support page]). The Neuros Synchronization Manager for Windows is available from the same link and now fully supports the addition of Vorbis files to the Neuros. *nix users can use Xiph.org's [http://www.xiph.org/positron/ Positron], Sean Starkey's Java [http://neurosdbm.sf.net/ Neuros Database Manipulator], or [http://www.sorune.com/ Sorune], all of which provide full Neuros database support and other features. Neuros II discontinued. Neuros III is planned but indefinite but they have a [http://open.neurosaudio.com/archives/Product%20Roadmap3-15-2005.htm roadmap].<br />
<br />
* [http://www.nextway.co.kr/ Nextway's] D Cube NHD-150D<br />
:This player uses a small 1,5 GB harddisk and supports MP3, WMA and Ogg Vorbis. It connects trough USB 2.0 and can broadcast music through a FM sender.<br />
<br />
* [http://www.pontis.de/ Pontis'] MX2020<br />
:There is now a firmware update for the MX2020 that adds Ogg Vorbis support, which is a portable player for movies, music and photos.<br />
<br />
* [http://www.modix-hd.com/ Rapsody's] RSH-100<br />
:It is similar to the Modix HD-3510, but supports USB host functionality additionally. This web site is dead. The Savit Micro Rapsody [http://www.savitmicro.co.kr/eng/product/tv/tv_rapsody.htm RSH-100] can be seen on their site.<br />
<br />
* [http://www.digitalnetworksna.com/rioaudio/ Rio's] Karma<br />
:The Rio [http://www.digitalnetworksna.com/shop/item.asp?model=261 Karma] is a portable player with a harddisk of 20 GB. It can decode MP3, Ogg Vorbis and FLAC. USB 2.0 is used to connect to PCs, but a docking station is also included which offers ethernet and RCA line-out support. IGN has written a [http://gear.ign.com/articles/458/458401p1.html review] about the gadget, articles about the Karma can be found at [http://www.riovolution.com Riovolution]. Note that firmware versions prior to 1.25 cause stability problems for some people, visit the [http://www.digitalnetworksna.com/support/rio/product.asp?prodID=113 support page] to get the newest version. The Karma was discontinued in March 2005, Rio (DNNA) effectively dissolved 27-July-2005 assets sold to [http://www.sigmatel.com/ SigmaTel].<br />
<br />
* [http://www.safa.com.hk/index_110R.html Safa] HMP-110R<br />
:A portable player with 1.5GB memory, FM-receiver, recording function, upgradeable firmware, etc.<br />
<br />
* [http://www.samsung.com Samsung] YH-J70<br />
:A portable Multimedia Jukebox as seen on their [http://www.samsung.com/common/microsite/exhibition/cebit2005/base.asp?pcode=IT01 Cebit 2005 Microsite]. Comes with 20/30GB disk, colour display, video player and USB host function<br />
<br />
* [http://www.sitecom.com/ Sitecom's] MP-330, MP-010<br />
:The MP-330 player uses a 4,4 GB harddrive, USB 2.0 and supports MP3, WMA and Ogg Vorbis (mentioned in the manual). The MP-010 is a portable media player. As such it supports music, movies and pictures. This includes MP3, WMA, Ogg Vorbis, MPEG-1/-2/-4. It has a capacity of 40GB, comes with a remote control and has various ports for the TV.<br />
<br />
* [http://www.teac.de/ TEAC] MP-1000, MP-2000<br />
:TEAC MP-1000 is an ultra-compact harddrive player with 1.5GB capacity and only 70g mass. The follow-up model MP-2000 has 5 GB storage and supports the same formats (MP3, WMA, Ogg Vorbis).<br />
<br />
* [http://www.trekstor.de/ TrekStor's] iBeat 500, iBeat 300<br />
:The iBeat 500 is a portable harddisk player with 20 GB of storage. It supports MP3, WMA and Ogg Vorbis and uses USB 2.0 to connect to PCs. It has a FM radio and an in-built mic. It seems to be available only in Germany (looks like a rebadged Xclef HD-800). The iBeat 300 uses a 1,5 GB HDD and has a color display.<br />
<br />
* [http://www.unibrain.com/iZak Unibrain's] iZak<br />
:This is a portable USB hard disk with 40/80/100 GB of storage. It plays a wide range of video formats, including dixv/xvid/bvix/dvd iso. A good review can be found [http://www.mpeg-playcenter.com/modules/Reviews/reviews/Review_iZak.pdf here].<br />
:The most current firmware release supports Ogg Vorbis playback according to [http://www.unibrain.com/support/iZak/iZak_FAQ.htm Unibrain's iZak FAQ].<br />
<br />
* [http://www.xclef.com/ Xclef's] HD-800, HD-500<br />
:This is a harddisk player with 20/40/60 GB storage size, and can decode MP3, WMA, Ogg Vorbis and WAV. It has a FM radio and a mic for recording voice. Though not mentioned on the web site, the HD-500 is also supposed to decode Ogg Vorbis.<br />
<br />
== CD/DVD Audio Players ==<br />
<br />
* [http://www.ifreemax.com/ Freemax's] FW-960<br />
:This CD-R portable supports Ogg Vorbis playback out of the box. It has 48 hours of WMA playback if an external battery pack (2 AA batteries) is used. The FreeMax FW-960 is also known as the mpman MP-CD550.<br />
<br />
* [http://www.exonion.com/ Havin's] (link dead) Exonion HVC-400E, [http://www.princeton.co.jp/ Princeton's] Pocket Beat airCD<br />
:The Havin HVC-400E, also known as the Princeton airCD is probably on sale in Japan since late November, 2003.<br />
<br />
* [http://www.iriver.com/product/info.asp?p_name=iMP-550 iRiver] iMP-250, iMP-350, iMP-400, iMP-550, iMP-700(T)<br />
:Ogg Vorbis is supported only through latest beta firmwares, still some bitrate restriction which may vary depending on the model (min=96kbps, max=160kbps). The iMP-550 supports maximum bitrate up to 256kps (still 96kbps as minimum). Also note the latest iMP-450 does not support OGG for the moment, a future upgrade may correct this... The iMP-700T with firmware 1.40 supports bitrates between 96 and 210 kbps, and .ogg files are generally not as loud as .mp3 files.<br />
<br />
* [http://www.samsungusa.com/ Samsung's] MCD-CM600<br />
:The MCD-CM600 is now available in Korea. It is a CD portable that can play Vorbis, MP3, and WMA.<br />
<br />
* [http://www.roadstar.com/ Roadstar] PCD-5960WOMPT<br />
<br />
== Portable Digital Assistants (PDAs) ==<br />
<br />
PDAs are also cable of operating as portable music players using available software applications. Please visit [http://wiki.xiph.org/index.php/VorbisSoftwarePlayers VorbisSoftwarePlayers] for more information.<br />
<br />
------------</div>Gumboothttps://wiki.xiph.org/index.php?title=Main_Page&diff=2184Main Page2005-11-29T23:12:37Z<p>Gumboot: revert spam</p>
<hr />
<div>= Projects/Formats =<br />
<br />
In an effort to bring open-source ideals to the world of multimedia The Xiph.org Foundation ([[XiphOrg]]) develops a multitude of amazing products. <br />
<br />
== Container Formats ==<br />
<br />
* [[Ogg]]: Media container. This is our native format and the recommeded container for Xiph codecs.<br />
* [[OggSkeleton]]: Skeleton information on all logical content bitstreams in Ogg<br />
<br />
* [[SpeexRTP]]: RTP payload format for voice<br />
* [[VorbisRTP]]: RTP payload format for general audio<br />
* [[TheoraRTP]]: RTP payload format for video<br />
* [[XSPF]]: XML playlist format<br />
<br />
== Codecs ==<br />
* '''Compressed Codecs:'''<br />
** [[Vorbis]]: Audio codec with a [[Tremor|fixed point decoder]]<br />
** [[Theora]]: Video codec<br />
** [[FLAC]]: Free Lossless Audio Codec<br />
** [[Speex]]: Speech codec<br />
** [[OggMNG]]: A mapping for encapsulating the MNG animation format in Ogg<br />
* '''[[RawCodecs|Uncompressed Codecs]]:'''<br />
** Audio:<br />
*** [[OggPCM]]: Uncompressed PCM audio, primarily as an interchange codec<br />
*** [[OggPCM2]]: An Alternative Uncompressed PCM audio, under active development<br />
*** [[OggPCM3|Humorous PCM format]]: Uncompressed PCM audio - and a lot more!<br />
** Video:<br />
*** [[OggRGB]]: Uncompressed RGB video, primarily as an interchange codec, under active development <br />
*** [[OggYUV]]: Uncompressed YUV video, primarily as an interchange codec, under active development<br />
*** [[OggUVS]]: Uncompressed RGB and YUV video, under active development as an alternative to OggRGB and OggYUV.<br />
** Text & Hyperlinking:<br />
*** [[OggWrit]]: Text phrase codec (e.g. subtitles)<br />
*** [http://annodex.net/TR/draft-pfeiffer-cmml-02.txt CMML]: Continuous Media Markup Language, used for [http://www.annodex.net/ Annodex] and subtitles (xine, vlc, gstreamer, and DirectShow support)<br />
* '''Metadata Codecs:'''<br />
** [[Metadata]]: Arbitrary metadata stream format (vapourware so far)<br />
<br />
== Software for distributing media ==<br />
<br />
* [[Icecast]]: Streaming server<br />
* [[Ices]]: Source client for Icecast servers<br />
* [[IceShare]]: P2P content distribution<br />
<br />
== Other software ==<br />
<br />
* [[OggComponent/VorbisComponent]]: Wrappers to integrate Ogg-Vorbis into MacOsX<br />
<br />
= Demonstrations =<br />
<br />
Want to hear Xiph in action? These projects are using our codecs, formats, or libraries.<br />
<br />
* [[VorbisStreams]]: Stations streaming with the Vorbis codec<br />
* [[Games that use Vorbis]]: Games using the Vorbis codec for music or sound effects<br />
* [[VorbisHardware]]: Hardware players using the Vorbis codec<br />
* [http://www.tversity.com TVersity Media Server]: A UPNP/AV compliant media server that uses the Ogg Vorbis libraries to transcode audio files to the Ogg Vorbis format.<br />
<br />
= Project management =<br />
<br />
* [[MonthlyMeeting]]<br />
* [[MailingLists]]<br />
* [[Bounties]]<br />
* [[HyperFish]]<br />
<br />
= Wiki internal =<br />
* [[Sandbox]]: Testbed for testing editing skills.<br />
* [[Translations]]: What about some translation work</div>Gumboothttps://wiki.xiph.org/index.php?title=Main_Page&diff=2175Main Page2005-11-26T19:31:50Z<p>Gumboot: revert spam</p>
<hr />
<div>= Projects/Formats =<br />
<br />
In an effort to bring open-source ideals to the world of multimedia The Xiph.org Foundation ([[XiphOrg]]) develops a multitude of amazing products. <br />
<br />
== Container Formats ==<br />
<br />
* [[Ogg]]: Media container. This is our native format and the recommeded container for Xiph codecs.<br />
* [[OggSkeleton]]: Skeleton information on all logical content bitstreams in Ogg<br />
<br />
* [[SpeexRTP]]: RTP payload format for voice<br />
* [[VorbisRTP]]: RTP payload format for general audio<br />
* [[TheoraRTP]]: RTP payload format for video<br />
* [[XSPF]]: XML playlist format<br />
<br />
== Codecs ==<br />
* '''Compressed Codecs:'''<br />
** [[Vorbis]]: Audio codec with a [[Tremor|fixed point decoder]]<br />
** [[Theora]]: Video codec<br />
** [[FLAC]]: Free Lossless Audio Codec<br />
** [[Speex]]: Speech codec<br />
** [[OggMNG]]: A mapping for encapsulating the MNG animation format in Ogg<br />
* '''[[RawCodecs|Uncompressed Codecs]]:'''<br />
** Audio:<br />
*** [[OggPCM]]: Uncompressed PCM audio, primarily as an interchange codec<br />
*** [[OggPCM2]]: An Alternative Uncompressed PCM audio, under active development<br />
*** [[OggPCM3|Humorous PCM format]]: Uncompressed PCM audio - and a lot more!<br />
** Video:<br />
*** [[OggRGB]]: Uncompressed RGB video, primarily as an interchange codec, under active development <br />
*** [[OggYUV]]: Uncompressed YUV video, primarily as an interchange codec, under active development<br />
*** [[OggUVS]]: Uncompressed RGB and YUV video, under active development as an alternative to OggRGB and OggYUV.<br />
** Text & Hyperlinking:<br />
*** [[OggWrit]]: Text phrase codec (e.g. subtitles)<br />
*** [http://annodex.net/TR/draft-pfeiffer-cmml-02.txt CMML]: Continuous Media Markup Language, used for [http://www.annodex.net/ Annodex] and subtitles (xine, vlc, gstreamer, and DirectShow support)<br />
* '''Metadata Codecs:'''<br />
** [[Metadata]]: Arbitrary metadata stream format (vapourware so far)<br />
<br />
== Software for distributing media ==<br />
<br />
* [[Icecast]]: Streaming server<br />
* [[Ices]]: Source client for Icecast servers<br />
* [[IceShare]]: P2P content distribution<br />
<br />
== Other software ==<br />
<br />
* [[OggComponent/VorbisComponent]]: Wrappers to integrate Ogg-Vorbis into MacOsX<br />
<br />
= Demonstrations =<br />
<br />
Want to hear Xiph in action? These projects are using our codecs, formats, or libraries.<br />
<br />
* [[VorbisStreams]]: Stations streaming with the Vorbis codec<br />
* [[Games that use Vorbis]]: Games using the Vorbis codec for music or sound effects<br />
* [[VorbisHardware]]: Hardware players using the Vorbis codec<br />
* [http://www.tversity.com TVersity Media Server]: A UPNP/AV compliant media server that uses the Ogg Vorbis libraries to transcode audio files to the Ogg Vorbis format.<br />
<br />
= Project management =<br />
<br />
* [[MonthlyMeeting]]<br />
* [[MailingLists]]<br />
* [[Bounties]]<br />
* [[HyperFish]]<br />
<br />
= Wiki internal =<br />
* [[Sandbox]]: Testbed for testing editing skills.<br />
* [[Translations]]: What about some translation work</div>Gumboothttps://wiki.xiph.org/index.php?title=XiphWiki:Sandbox&diff=2169XiphWiki:Sandbox2005-11-24T10:55:12Z<p>Gumboot: revert spam</p>
<hr />
<div>= Headline 1 =<br />
== Headline 2 ==<br />
=== Headline 3 ===<br />
=== Headline 4 ===<br />
{| border=2 cellpadding=10<br />
|+ '''Table test'''<br />
| x || 'One' || ''Two2'' || '''Three'''<br />
|-<br />
! what is this<br />
| 'yes' <br />
| ''no'' <br />
! maybe<br />
|-<br />
!<br />
{| border=1 cellpadding =2<br />
|+ for you<br />
| a<br />
| b<br />
| c<br />
|-<br />
| d || e|| f<br />
|}<br />
| 1 || 2 || 3<br />
|}<br />
<br />
This is a good test<br />
<br />
== Headline 5 ==<br />
<br />
* Item 1<br />
* Item 2<br />
* Item 3<br />
<br />
<br />
LoSSSSSSSSSSSSSSSSSSSSSSSSSSSSSStus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.<br />
<br />
Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.<br />
<br />
Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.<br />
<br />
It has been reported that links to ".com" sites don't work: [http://www.vorbis.com/ Vorbis Website]<br />
<br />
== Headline 2 ==<br />
Good goodess, don't you hate wiki spam?</div>Gumboothttps://wiki.xiph.org/index.php?title=Main_Page&diff=2165Main Page2005-11-24T01:07:48Z<p>Gumboot: revert spam</p>
<hr />
<div>= Projects/Formats =<br />
<br />
In an effort to bring open-source ideals to the world of multimedia The Xiph.org Foundation ([[XiphOrg]]) develops a multitude of amazing products. <br />
<br />
== Container Formats ==<br />
<br />
* [[Ogg]]: Media container. This is our native format and the recommeded container for Xiph codecs.<br />
* [[OggSkeleton]]: Skeleton information on all logical content bitstreams in Ogg<br />
<br />
* [[SpeexRTP]]: RTP payload format for voice<br />
* [[VorbisRTP]]: RTP payload format for general audio<br />
* [[TheoraRTP]]: RTP payload format for video<br />
* [[XSPF]]: XML playlist format<br />
<br />
== Codecs ==<br />
* '''Compressed Codecs:'''<br />
** [[Vorbis]]: Audio codec with a [[Tremor|fixed point decoder]]<br />
** [[Theora]]: Video codec<br />
** [[FLAC]]: Free Lossless Audio Codec<br />
** [[Speex]]: Speech codec<br />
** [[OggMNG]]: A mapping for encapsulating the MNG animation format in Ogg<br />
* '''[[RawCodecs|Uncompressed Codecs]]:'''<br />
** Audio:<br />
*** [[OggPCM]]: Uncompressed PCM audio, primarily as an interchange codec<br />
*** [[OggPCM2]]: An Alternative Uncompressed PCM audio, under active development<br />
*** [[OggPCM3|Humorous PCM format]]: Uncompressed PCM audio - and a lot more!<br />
** Video:<br />
*** [[OggRGB]]: Uncompressed RGB video, primarily as an interchange codec, under active development <br />
*** [[OggYUV]]: Uncompressed YUV video, primarily as an interchange codec, under active development<br />
*** [[OggUVS]]: Uncompressed RGB and YUV video, under active development as an alternative to OggRGB and OggYUV.<br />
** Text & Hyperlinking:<br />
*** [[OggWrit]]: Text phrase codec (e.g. subtitles)<br />
*** [http://annodex.net/TR/draft-pfeiffer-cmml-02.txt CMML]: Continuous Media Markup Language, used for [http://www.annodex.net/ Annodex] and subtitles (xine, vlc, gstreamer, and DirectShow support)<br />
* '''Metadata Codecs:'''<br />
** [[Metadata]]: Arbitrary metadata stream format (vapourware so far)<br />
<br />
== Software for distributing media ==<br />
<br />
* [[Icecast]]: Streaming server<br />
* [[Ices]]: Source client for Icecast servers<br />
* [[IceShare]]: P2P content distribution<br />
<br />
== Other software ==<br />
<br />
* [[OggComponent/VorbisComponent]]: Wrappers to integrate Ogg-Vorbis into MacOsX<br />
<br />
= Demonstrations =<br />
<br />
Want to hear Xiph in action? These projects are using our codecs, formats, or libraries.<br />
<br />
* [[VorbisStreams]]: Stations streaming with the Vorbis codec<br />
* [[Games that use Vorbis]]: Games using the Vorbis codec for music or sound effects<br />
* [[VorbisHardware]]: Hardware players using the Vorbis codec<br />
* [http://www.tversity.com TVersity Media Server]: A UPNP/AV compliant media server that uses the Ogg Vorbis libraries to transcode audio files to the Ogg Vorbis format.<br />
<br />
= Project management =<br />
<br />
* [[MonthlyMeeting]]<br />
* [[MailingLists]]<br />
* [[Bounties]]<br />
* [[HyperFish]]<br />
<br />
= Wiki internal =<br />
* [[Sandbox]]: Testbed for testing editing skills.<br />
* [[Translations]]: What about some translation work</div>Gumboothttps://wiki.xiph.org/index.php?title=Main_Page&diff=2161Main Page2005-11-22T23:05:11Z<p>Gumboot: revert spam</p>
<hr />
<div>= Projects/Formats =<br />
<br />
In an effort to bring open-source ideals to the world of multimedia The Xiph.org Foundation ([[XiphOrg]]) develops a multitude of amazing products. <br />
<br />
== Container Formats ==<br />
<br />
* [[Ogg]]: Media container. This is our native format and the recommeded container for Xiph codecs.<br />
* [[OggSkeleton]]: Skeleton information on all logical content bitstreams in Ogg<br />
<br />
* [[SpeexRTP]]: RTP payload format for voice<br />
* [[VorbisRTP]]: RTP payload format for general audio<br />
* [[TheoraRTP]]: RTP payload format for video<br />
* [[XSPF]]: XML playlist format<br />
<br />
== Codecs ==<br />
* '''Compressed Codecs:'''<br />
** [[Vorbis]]: Audio codec with a [[Tremor|fixed point decoder]]<br />
** [[Theora]]: Video codec<br />
** [[FLAC]]: Free Lossless Audio Codec<br />
** [[Speex]]: Speech codec<br />
** [[OggMNG]]: A mapping for encapsulating the MNG animation format in Ogg<br />
* '''[[RawCodecs|Uncompressed Codecs]]:'''<br />
** Audio:<br />
*** [[OggPCM]]: Uncompressed PCM audio, primarily as an interchange codec<br />
*** [[OggPCM2]]: An Alternative Uncompressed PCM audio, under active development<br />
*** [[OggPCM3|Humorous PCM format]]: Uncompressed PCM audio - and a lot more!<br />
** Video:<br />
*** [[OggRGB]]: Uncompressed RGB video, primarily as an interchange codec, under active development <br />
*** [[OggYUV]]: Uncompressed YUV video, primarily as an interchange codec, under active development<br />
*** [[OggUVS]]: Uncompressed RGB and YUV video, under active development as an alternative to OggRGB and OggYUV.<br />
** Text & Hyperlinking:<br />
*** [[OggWrit]]: Text phrase codec (e.g. subtitles)<br />
*** [http://annodex.net/TR/draft-pfeiffer-cmml-02.txt CMML]: Continuous Media Markup Language, used for [http://www.annodex.net/ Annodex] and subtitles (xine, vlc, gstreamer, and DirectShow support)<br />
* '''Metadata Codecs:'''<br />
** [[Metadata]]: Arbitrary metadata stream format (vapourware so far)<br />
<br />
== Software for distributing media ==<br />
<br />
* [[Icecast]]: Streaming server<br />
* [[Ices]]: Source client for Icecast servers<br />
* [[IceShare]]: P2P content distribution<br />
<br />
== Other software ==<br />
<br />
* [[OggComponent/VorbisComponent]]: Wrappers to integrate Ogg-Vorbis into MacOsX<br />
<br />
= Demonstrations =<br />
<br />
Want to hear Xiph in action? These projects are using our codecs, formats, or libraries.<br />
<br />
* [[VorbisStreams]]: Stations streaming with the Vorbis codec<br />
* [[Games that use Vorbis]]: Games using the Vorbis codec for music or sound effects<br />
* [[VorbisHardware]]: Hardware players using the Vorbis codec<br />
* [http://www.tversity.com TVersity Media Server]: A UPNP/AV compliant media server that uses the Ogg Vorbis libraries to transcode audio files to the Ogg Vorbis format.<br />
<br />
= Project management =<br />
<br />
* [[MonthlyMeeting]]<br />
* [[MailingLists]]<br />
* [[Bounties]]<br />
* [[HyperFish]]<br />
<br />
= Wiki internal =<br />
* [[Sandbox]]: Testbed for testing editing skills.<br />
* [[Translations]]: What about some translation work</div>Gumboothttps://wiki.xiph.org/index.php?title=Main_Page&diff=2155Main Page2005-11-21T15:02:29Z<p>Gumboot: revert spam</p>
<hr />
<div>= Projects/Formats =<br />
<br />
In an effort to bring open-source ideals to the world of multimedia The Xiph.org Foundation ([[XiphOrg]]) develops a multitude of amazing products. <br />
<br />
== Container Formats ==<br />
<br />
* [[Ogg]]: Media container. This is our native format and the recommeded container for Xiph codecs.<br />
* [[OggSkeleton]]: Skeleton information on all logical content bitstreams in Ogg<br />
<br />
* [[SpeexRTP]]: RTP payload format for voice<br />
* [[VorbisRTP]]: RTP payload format for general audio<br />
* [[TheoraRTP]]: RTP payload format for video<br />
* [[XSPF]]: XML playlist format<br />
<br />
== Codecs ==<br />
* '''Compressed Codecs:'''<br />
** [[Vorbis]]: Audio codec with a [[Tremor|fixed point decoder]]<br />
** [[Theora]]: Video codec<br />
** [[FLAC]]: Free Lossless Audio Codec<br />
** [[Speex]]: Speech codec<br />
** [[OggMNG]]: A mapping for encapsulating the MNG animation format in Ogg<br />
* '''[[RawCodecs|Uncompressed Codecs]]:'''<br />
** Audio:<br />
*** [[OggPCM]]: Uncompressed PCM audio, primarily as an interchange codec<br />
*** [[OggPCM2]]: An Alternative Uncompressed PCM audio, under active development<br />
*** [[OggPCM3|Humorous PCM format]]: Uncompressed PCM audio - and a lot more!<br />
** Video:<br />
*** [[OggRGB]]: Uncompressed RGB video, primarily as an interchange codec, under active development <br />
*** [[OggYUV]]: Uncompressed YUV video, primarily as an interchange codec, under active development<br />
*** [[OggUVS]]: Uncompressed RGB and YUV video, under active development as an alternative to OggRGB and OggYUV.<br />
** Text & Hyperlinking:<br />
*** [[OggWrit]]: Text phrase codec (e.g. subtitles)<br />
*** [http://annodex.net/TR/draft-pfeiffer-cmml-02.txt CMML]: Continuous Media Markup Language, used for [http://www.annodex.net/ Annodex] and subtitles (xine, vlc, gstreamer, and DirectShow support)<br />
* '''Metadata Codecs:'''<br />
** [[Metadata]]: Arbitrary metadata stream format (vapourware so far)<br />
<br />
== Software for distributing media ==<br />
<br />
* [[Icecast]]: Streaming server<br />
* [[Ices]]: Source client for Icecast servers<br />
* [[IceShare]]: P2P content distribution<br />
<br />
== Other software ==<br />
<br />
* [[OggComponent/VorbisComponent]]: Wrappers to integrate Ogg-Vorbis into MacOsX<br />
<br />
= Demonstrations =<br />
<br />
Want to hear Xiph in action? These projects are using our codecs, formats, or libraries.<br />
<br />
* [[VorbisStreams]]: Stations streaming with the Vorbis codec<br />
* [[Games that use Vorbis]]: Games using the Vorbis codec for music or sound effects<br />
* [[VorbisHardware]]: Hardware players using the Vorbis codec<br />
* [http://www.tversity.com TVersity Media Server]: A UPNP/AV compliant media server that uses the Ogg Vorbis libraries to transcode audio files to the Ogg Vorbis format.<br />
<br />
= Project management =<br />
<br />
* [[MonthlyMeeting]]<br />
* [[MailingLists]]<br />
* [[Bounties]]<br />
* [[HyperFish]]<br />
<br />
= Wiki internal =<br />
* [[Sandbox]]: Testbed for testing editing skills.<br />
* [[Translations]]: What about some translation work</div>Gumboothttps://wiki.xiph.org/index.php?title=User:Gumboot&diff=3213User:Gumboot2005-11-21T09:29:23Z<p>Gumboot: </p>
<hr />
<div>.</div>Gumboothttps://wiki.xiph.org/index.php?title=Main_Page&diff=2150Main Page2005-11-19T19:57:20Z<p>Gumboot: revert spam</p>
<hr />
<div>= Projects/Formats =<br />
<br />
In an effort to bring open-source ideals to the world of multimedia The Xiph.org Foundation ([[XiphOrg]]) develops a multitude of amazing products. <br />
<br />
== Container Formats ==<br />
<br />
* [[Ogg]]: Media container. This is our native format and the recommeded container for Xiph codecs.<br />
* [[OggSkeleton]]: Skeleton information on all logical content bitstreams in Ogg<br />
<br />
* [[SpeexRTP]]: RTP payload format for voice<br />
* [[VorbisRTP]]: RTP payload format for general audio<br />
* [[TheoraRTP]]: RTP payload format for video<br />
* [[XSPF]]: XML playlist format<br />
<br />
== Codecs ==<br />
* '''Compressed Codecs:'''<br />
** [[Vorbis]]: Audio codec with a [[Tremor|fixed point decoder]]<br />
** [[Theora]]: Video codec<br />
** [[FLAC]]: Free Lossless Audio Codec<br />
** [[Speex]]: Speech codec<br />
** [[OggMNG]]: A mapping for encapsulating the MNG animation format in Ogg<br />
* '''[[RawCodecs|Uncompressed Codecs]]:'''<br />
** Audio:<br />
*** [[OggPCM]]: Uncompressed PCM audio, primarily as an interchange codec<br />
*** [[OggPCM2]]: An Alternative Uncompressed PCM audio, under active development<br />
*** [[OggPCM3|Humorous PCM format]]: Uncompressed PCM audio - and a lot more!<br />
** Video:<br />
*** [[OggRGB]]: Uncompressed RGB video, primarily as an interchange codec, under active development <br />
*** [[OggYUV]]: Uncompressed YUV video, primarily as an interchange codec, under active development<br />
*** [[OggUVS]]: Uncompressed RGB and YUV video, under active development as an alternative to OggRGB and OggYUV.<br />
** Text & Hyperlinking:<br />
*** [[OggWrit]]: Text phrase codec (e.g. subtitles)<br />
*** [http://annodex.net/TR/draft-pfeiffer-cmml-02.txt CMML]: Continuous Media Markup Language, used for [http://www.annodex.net/ Annodex] and subtitles (xine, vlc, gstreamer, and DirectShow support)<br />
* '''Metadata Codecs:'''<br />
** [[Metadata]]: Arbitrary metadata stream format (vapourware so far)<br />
<br />
== Software for distributing media ==<br />
<br />
* [[Icecast]]: Streaming server<br />
* [[Ices]]: Source client for Icecast servers<br />
* [[IceShare]]: P2P content distribution<br />
<br />
== Other software ==<br />
<br />
* [[OggComponent/VorbisComponent]]: Wrappers to integrate Ogg-Vorbis into MacOsX<br />
<br />
= Demonstrations =<br />
<br />
Want to hear Xiph in action? These projects are using our codecs, formats, or libraries.<br />
<br />
* [[VorbisStreams]]: Stations streaming with the Vorbis codec<br />
* [[Games that use Vorbis]]: Games using the Vorbis codec for music or sound effects<br />
* [[VorbisHardware]]: Hardware players using the Vorbis codec<br />
* [http://www.tversity.com TVersity Media Server]: A UPNP/AV compliant media server that uses the Ogg Vorbis libraries to transcode audio files to the Ogg Vorbis format.<br />
<br />
= Project management =<br />
<br />
* [[MonthlyMeeting]]<br />
* [[MailingLists]]<br />
* [[Bounties]]<br />
* [[HyperFish]]<br />
<br />
= Wiki internal =<br />
* [[Sandbox]]: Testbed for testing editing skills.<br />
* [[Translations]]: What about some translation work</div>Gumboothttps://wiki.xiph.org/index.php?title=Talk:OggUVS&diff=3133Talk:OggUVS2005-11-19T15:01:22Z<p>Gumboot: /* Field rates and timebase */ Shutter rate distinction.</p>
<hr />
<div>== Caveats ==<br />
<br />
* At very low resolutions it's possible to encode a video that has incomplete timing information because more than one frame could fit into an Ogg page. This represents data loss in the case of variable frame rate video (a common case in devices that are limited to such low resolutions). libogg's default limit of 4kB isn't meaningful; the actual limit is ~64kB. Are people really willing to impose a rule that no more than one field can finish within a page? --[[User:Gumboot|Gumboot]] 06:34, 19 Nov 2005 (PST)<br />
<br />
== Field rates and timebase ==<br />
<br />
The combination of field rate and timebase information amounts to only two scalars. The field rate can be expressed as the number of time steps between each frame. If this is imprecise then the timebase should be increased, or it can be specified that the step rate varies between k and k+1. Multiplying the timebase by the Frame Rate Numerator will have all the original precision. --[[User:Gumboot|Gumboot]] 06:44, 19 Nov 2005 (PST)<br />
<br />
The distinction between shutter rate and field rate has not been made clear. It is possible, and not uncommon, to issue two fields from the same sample interval separately. It is also possible to have no shutter at all, and for every pixel to be sampled in a different time interval. Be careful to note the common case where the actual shutter is 24Hz, but the effective shutter rate needs to be declared as 25Hz to be consistent with the audio track and the field rate. --[[User:Gumboot|Gumboot]] 07:01, 19 Nov 2005 (PST)</div>Gumboothttps://wiki.xiph.org/index.php?title=Talk:OggUVS&diff=2143Talk:OggUVS2005-11-19T14:44:52Z<p>Gumboot: header uniformity</p>
<hr />
<div>== Caveats ==<br />
<br />
* At very low resolutions it's possible to encode a video that has incomplete timing information because more than one frame could fit into an Ogg page. This represents data loss in the case of variable frame rate video (a common case in devices that are limited to such low resolutions). libogg's default limit of 4kB isn't meaningful; the actual limit is ~64kB. Are people really willing to impose a rule that no more than one field can finish within a page? --[[User:Gumboot|Gumboot]] 06:34, 19 Nov 2005 (PST)<br />
<br />
== Field rates and timebase ==<br />
<br />
The combination of field rate and timebase information amounts to only two scalars. The field rate can be expressed as the number of time steps between each frame. If this is imprecise then the timebase should be increased, or it can be specified that the step rate varies between k and k+1. Multiplying the timebase by the Frame Rate Numerator will have all the original precision. --[[User:Gumboot|Gumboot]] 06:44, 19 Nov 2005 (PST)</div>Gumboothttps://wiki.xiph.org/index.php?title=Talk:OggUVS&diff=2142Talk:OggUVS2005-11-19T14:44:26Z<p>Gumboot: Field rates and timebase</p>
<hr />
<div>===Caveats===<br />
* At very low resolutions it's possible to encode a video that has incomplete timing information because more than one frame could fit into an Ogg page. This represents data loss in the case of variable frame rate video (a common case in devices that are limited to such low resolutions). libogg's default limit of 4kB isn't meaningful; the actual limit is ~64kB. Are people really willing to impose a rule that no more than one field can finish within a page? --[[User:Gumboot|Gumboot]] 06:34, 19 Nov 2005 (PST)<br />
<br />
== Field rates and timebase ==<br />
<br />
The combination of field rate and timebase information amounts to only two scalars. The field rate can be expressed as the number of time steps between each frame. If this is imprecise then the timebase should be increased, or it can be specified that the step rate varies between k and k+1. Multiplying the timebase by the Frame Rate Numerator will have all the original precision. --[[User:Gumboot|Gumboot]] 06:44, 19 Nov 2005 (PST)</div>Gumboothttps://wiki.xiph.org/index.php?title=Talk:OggUVS&diff=2141Talk:OggUVS2005-11-19T14:34:54Z<p>Gumboot: Begin list of caveats for discussion</p>
<hr />
<div>===Caveats===<br />
* At very low resolutions it's possible to encode a video that has incomplete timing information because more than one frame could fit into an Ogg page. This represents data loss in the case of variable frame rate video (a common case in devices that are limited to such low resolutions). libogg's default limit of 4kB isn't meaningful; the actual limit is ~64kB. Are people really willing to impose a rule that no more than one field can finish within a page? --[[User:Gumboot|Gumboot]] 06:34, 19 Nov 2005 (PST)</div>Gumboothttps://wiki.xiph.org/index.php?title=OggPCM&diff=2160OggPCM2005-11-18T10:08:58Z<p>Gumboot: /* Channel Mapping Header */ Surround channels</p>
<hr />
<div>'''This page was created as an alternative to the original [[OggPCM]]. The matter is currently a topic of [http://lists.xiph.org/pipermail/ogg-dev/2005-November/thread.html heated debate] and is now being voted on'''<br />
<br />
== Alternate format for OggPCM ==<br />
<br />
The following is an alternate format for OggPCM. This is a work in progress and not a final proposal.<br />
<br />
Note that unless otherwise noted, all multi-byte fields use the network byte order (big endian). The first packed in a stream MUST be the main header packet. The second packet MUST be the comment packet. Some extra header packets MAY be included after the comment header, provided this is identified in the main header. The packets that follow MUST all be data packets.<br />
<br />
=== Main Header Packet ===<br />
Multibyte fields in the header packets are packed in big endian order, to be consistent with network byte order. A header packet contains the following fields: <br />
<br />
64 "PCM " Codec identifier<br />
16 0x00 Version Major (breaks backwards compatability to increment)<br />
16 0x00 Version Minor (backwards compatable, ie, more supported format id's)<br />
32 [uint] PCM format<br />
32 [uint] Sampling rate [Hz]<br />
8 [uint] Significant bits<br />
8 [uint] Number of Channels (< 256)<br />
16 [uint] Maximum number of frames per packet<br />
32 [uint] Number of extra header packets<br />
<br />
A PCM "frame" is composed of samples for all channels at a given time.<br />
<br />
The "Codec identifier" is 64 bit long since most other Ogg codecs specify their identifier within the first 64 bits rather than the first 32 bits, so this allows applications to match on all 64 bits consistently.<br />
<br />
The "Maximum number of frames per packet" field is meant to notify an application reading the file that no data packet will contain more than a certain number of frames. This not only makes implementation easier, but also provides information on how much needs to be buffered when streaming PCM files. A value of 0 means a maximum of 65536 frames. Implementations SHOULD make this field such that packets do not get split into multiple pages.<br />
<br />
The "significant bits" field specifies how many bits are actually used. The other bits MUST be zero. This can be used to support audio with any resolution. For example, 12-bit PCM can be supported as "16 bit PCM" for the format and 12 for the number of significant bits.<br />
<br />
For streams where the number of significant bits is the same as the bit width specified by the format, the significant bits field may be set to zero.<br />
<br />
For streams where the number of significant bits is less than that specified by the bit width, the data shall be justified to fill the most significant bits. For 12 bit PCM in a 16 bit format, the 12 valid bits will occupy the 12 most significant bits of the 16 bit word and the least significant 4 bits shall be zero.<br />
<br />
Since the main header packet and the comment packet are mandatory, the "extra header packets" field counts any additional header packets (aside from these two) that can be provided before the start of the data packets.<br />
<br />
=== Comment packet ===<br />
<br />
The codec header is followed by a "vorbis comment" packet and by optional extra headers, if any. The format used is the same as for Vorbis with the exception that there is no packet identifier (so the packet is exactly like it is for Speex).<br />
<br />
=== Extra Headers (optional) ===<br />
<br />
Extra header packets contain additional information about the OggPCM stream. Each extra header is defined as:<br />
<br />
32 [uint] Header ID<br />
... Header data<br />
<br />
Two examples for such optional extra header packets are the channel mapping and the channel conversion header packets.<br />
<br />
==== Channel Mapping Header ====<br />
<br />
The channel mapping header is defined as:<br />
<br />
32 0x00000000 Header ID<br />
16 [uint] Major version<br />
16 [uint] Minor version<br />
32 [uint] Channel type<br />
32xN [uint] Channel map (one for each channel)<br />
<br />
All channel_types less than 0x80000000 are reserved for use by Xiph; 0x80000000 and above are allowed for application specific extensions.<br />
<br />
This scheme allows for 2^31 -1 Xiph defined channel map types and 2^32 distinct channel names.<br />
<br />
Exampe values for channel map type might be:<br />
<br />
OGG_CHANNEL_MAP_MONO = 0<br />
OGG_CHANNEL_MAP_STEREO = 1<br />
OGG_CHANNEL_MAP_MS_WAVE = 2<br />
OGG_CHANNEL_MAP_QUADROPHONIC = 3<br />
<br />
and defined channels might be:<br />
<br />
OGG_CHANNEL_FRONT_CENTER = 0<br />
OGG_CHANNEL_FRONT_LEFT = 1<br />
OGG_CHANNEL_FRONT_RIGHT = 2<br />
OGG_CHANNEL_SURROUND_LEFT = 3<br />
OGG_CHANNEL_SURROUND_RIGHT = 4<br />
OGG_CHANNEL_SURROUND_REAR = 5<br />
OGG_CHANNEL_REAR_LEFT = 6<br />
OGG_CHANNEL_REAR_RIGHT = 7<br />
OGG_CHANNEL_LFE_CENTER = 8<br />
OGG_CHANNEL_LFE_LEFT = 9<br />
OGG_CHANNEL_LFE_RIGHT = 10<br />
<br />
This leaves two ways to define a stereo file:<br />
<br />
channel_type = OGG_CHANNEL_MAP_STEREO<br />
channel_map [0] = OGG_CHANNEL_FRONT_LEFT<br />
channel_map [1] = OGG_CHANNEL_FRONT_RIGHT<br />
<br />
or as:<br />
<br />
channel_type = OGG_CHANNEL_MAP_STEREO<br />
channel_map [0] = OGG_CHANNEL_FRONT_RIGHT<br />
channel_map [1] = OGG_CHANNEL_FRONT_LEFT<br />
<br />
==== Channel Conversion Header ====<br />
<br />
Any number of channel conversion headers can be specified. This header specifies how to down-mix the data to another format.<br />
<br />
32 0x00000001 Remixing Header Id<br />
16 [uint] Major version<br />
16 [uint] Minor version<br />
32 [uint] Target Channel type<br />
32xMxN [sint] Target Channel (M) x Src Channel (N) Gain array<br />
<br />
The ordering of the mixing matrix is such that source channel gains are consecutive. The gain (note: *signed* integer) has the 16 MSBs for the integer part (including sign) and 16 bits for the fracional part of the gain. Note: the gain can be negative.<br />
<br />
=== Data Packets ===<br />
<br />
Data packets contain the raw PCM audio in interleaved format (complete frames are encoded sequentially) with the following definitions/restrictions:<br />
<br />
* A PCM "frame" is composed of samples for all channels at a given time.<br />
* Any OggPCM packet MUST only contain complete frames (ie samples for all channels at a given sampling instance). Partial frames are forbidden.<br />
* There is no padding allowed in a frame except when some bits (<8) are needed to complete a byte. This means that packet size has a direct relationship to the number of frames in the packet (for purposes of seeking).<br />
* Recommended packet size is smaller than 4k since interleaving and seeking in Ogg bitstreams is done on the resolution of packets and thus larger packet sizes create suboptimal bitstreams.<br />
<br />
=== Supported PCM Formats ===<br />
<br />
Format ID Short Name Description<br />
-- Integer coding<br />
0x00000000 OGGPCM_FMT_S8 Signed integer 8 bit<br />
0x00000001 OGGPCM_FMT_U8 Unsigned integer 8 bit<br />
0x00000002 OGGPCM_FMT_S16_LE Signed integer 16 bit little endian<br />
0x00000003 OGGPCM_FMT_S16_BE Signed integer 16 bit big endian<br />
0x00000004 OGGPCM_FMT_S24_LE Signed integer 24 bit little endian<br />
0x00000005 OGGPCM_FMT_S24_BE Signed integer 24 bit big endian<br />
0x00000006 OGGPCM_FMT_S32_LE Signed integer 32 bit little endian<br />
0x00000007 OGGPCM_FMT_S32_BE Signed integer 32 bit big endian<br />
--<br />
-- Compressed PCM<br />
0x00000010 OGGPCM_FMT_ULAW G.711 u-law encoding (8 bit)<br />
0x00000011 OGGPCM_FMT_ALAW G.711 A-law encoding (8 bit)<br />
--<br />
-- IEEE Floating point coding<br />
0x00000020 OGGPCM_FMT_FLT32_LE IEEE Float [-1,1] 32 bit little endian<br />
0x00000021 OGGPCM_FMT_FLT32_BE IEEE Float [-1,1] 32 bit big endian<br />
0x00000022 OGGPCM_FMT_FLT64_LE IEEE Float [-1,1] 64 bit little endian<br />
0x00000023 OGGPCM_FMT_FLT64_BE IEEE Float [-1,1] 64 bit big endian<br />
<br />
Format IDs below 0x80000000 are reserved for use by Xiph and all the ones above are allowed for application-specific formats.<br />
<br />
=== Format Defaults ===<br />
<br />
(ideas by JMV, not yet approved by anyone else. Should be merged in respective header definition above if approved)<br />
<br />
In order to simplify implementations when it comes to channel mappings, several defaults are defined when no extra header is present.<br />
<br />
==== Channel Encoding ====<br />
<br />
* Files containing one channel are assumed to be plain mono files with:<br />
channel_type = OGG_CHANNEL_MAP_MONO<br />
channel_map [0] = OGG_CHANNEL_FRONT_CENTER<br />
<br />
* Files containing two channels are assumed to be stereo files with:<br />
channel_type = OGG_CHANNEL_MAP_STEREO<br />
channel_map [0] = OGG_CHANNEL_FRONT_LEFT<br />
channel_map [1] = OGG_CHANNEL_FRONT_RIGHT<br />
<br />
* Files containing four channels are assumed to be quadraphonic files with:<br />
channel_type = OGG_CHANNEL_MAP_QUADROPHONIC<br />
channel_map [0] = OGG_CHANNEL_FRONT_LEFT<br />
channel_map [1] = OGG_CHANNEL_FRONT_RIGHT<br />
channel_map [2] = OGG_CHANNEL_REAR_LEFT<br />
channel_map [3] = OGG_CHANNEL_REAR_RIGHT<br />
<br />
==== Channel Conversion ====<br />
<br />
* Stereo files SHOULD be converted to mono files by averaging the left channel and the right channel<br />
* Quadraphonic files SHOULD be converted to stereo files by averaging the corresponding rear and front channels.<br />
<br />
== Related Links ==<br />
Short info about AC-3: http://www.mediatwins.com/en/support/kb_topic_11.html<br />
<br />
AC-3 spec: http://www.atsc.org/standards/a_52a.pdf <br><br />
Note: around p34/140 it appears to be how the channel mapping is encoded.<br />
<br />
.wav extended headers for multi channel: http://www.microsoft.com/whdc/device/audio/multichaud.mspx<br />
<br />
General surround info: http://www.surroundassociates.com/fqmain.html</div>Gumboothttps://wiki.xiph.org/index.php?title=OggPCM&diff=2124OggPCM2005-11-18T09:54:54Z<p>Gumboot: s/subwoofer/LFE/; add left and right LFE for the crazy people.</p>
<hr />
<div>'''This page was created as an alternative to the original [[OggPCM]]. The matter is currently a topic of [http://lists.xiph.org/pipermail/ogg-dev/2005-November/thread.html heated debate] and is now being voted on'''<br />
<br />
== Alternate format for OggPCM ==<br />
<br />
The following is an alternate format for OggPCM. This is a work in progress and not a final proposal.<br />
<br />
Note that unless otherwise noted, all multi-byte fields use the network byte order (big endian). The first packed in a stream MUST be the main header packet. The second packet MUST be the comment packet. Some extra header packets MAY be included after the comment header, provided this is identified in the main header. The packets that follow MUST all be data packets.<br />
<br />
=== Main Header Packet ===<br />
Multibyte fields in the header packets are packed in big endian order, to be consistent with network byte order. A header packet contains the following fields: <br />
<br />
64 "PCM " Codec identifier<br />
16 0x00 Version Major (breaks backwards compatability to increment)<br />
16 0x00 Version Minor (backwards compatable, ie, more supported format id's)<br />
32 [uint] PCM format<br />
32 [uint] Sampling rate [Hz]<br />
8 [uint] Significant bits<br />
8 [uint] Number of Channels (< 256)<br />
16 [uint] Maximum number of frames per packet<br />
32 [uint] Number of extra header packets<br />
<br />
A PCM "frame" is composed of samples for all channels at a given time.<br />
<br />
The "Codec identifier" is 64 bit long since most other Ogg codecs specify their identifier within the first 64 bits rather than the first 32 bits, so this allows applications to match on all 64 bits consistently.<br />
<br />
The "Maximum number of frames per packet" field is meant to notify an application reading the file that no data packet will contain more than a certain number of frames. This not only makes implementation easier, but also provides information on how much needs to be buffered when streaming PCM files. A value of 0 means a maximum of 65536 frames. Implementations SHOULD make this field such that packets do not get split into multiple pages.<br />
<br />
The "significant bits" field specifies how many bits are actually used. The other bits MUST be zero. This can be used to support audio with any resolution. For example, 12-bit PCM can be supported as "16 bit PCM" for the format and 12 for the number of significant bits.<br />
<br />
For streams where the number of significant bits is the same as the bit width specified by the format, the significant bits field may be set to zero.<br />
<br />
For streams where the number of significant bits is less than that specified by the bit width, the data shall be justified to fill the most significant bits. For 12 bit PCM in a 16 bit format, the 12 valid bits will occupy the 12 most significant bits of the 16 bit word and the least significant 4 bits shall be zero.<br />
<br />
Since the main header packet and the comment packet are mandatory, the "extra header packets" field counts any additional header packets (aside from these two) that can be provided before the start of the data packets.<br />
<br />
=== Comment packet ===<br />
<br />
The codec header is followed by a "vorbis comment" packet and by optional extra headers, if any. The format used is the same as for Vorbis with the exception that there is no packet identifier (so the packet is exactly like it is for Speex).<br />
<br />
=== Extra Headers (optional) ===<br />
<br />
Extra header packets contain additional information about the OggPCM stream. Each extra header is defined as:<br />
<br />
32 [uint] Header ID<br />
... Header data<br />
<br />
Two examples for such optional extra header packets are the channel mapping and the channel conversion header packets.<br />
<br />
==== Channel Mapping Header ====<br />
<br />
The channel mapping header is defined as:<br />
<br />
32 0x00000000 Header ID<br />
16 [uint] Major version<br />
16 [uint] Minor version<br />
32 [uint] Channel type<br />
32xN [uint] Channel map (one for each channel)<br />
<br />
All channel_types less than 0x80000000 are reserved for use by Xiph; 0x80000000 and above are allowed for application specific extensions.<br />
<br />
This scheme allows for 2^31 -1 Xiph defined channel map types and 2^32 distinct channel names.<br />
<br />
Exampe values for channel map type might be:<br />
<br />
OGG_CHANNEL_MAP_MONO = 0<br />
OGG_CHANNEL_MAP_STEREO = 1<br />
OGG_CHANNEL_MAP_MS_WAVE = 2<br />
OGG_CHANNEL_MAP_QUADROPHONIC = 3<br />
<br />
and defined channels might be:<br />
<br />
OGG_CHANNEL_FRONT_CENTER = 0<br />
OGG_CHANNEL_FRONT_LEFT = 1<br />
OGG_CHANNEL_FRONT_RIGHT = 2<br />
OGG_CHANNEL_REAR_LEFT = 3<br />
OGG_CHANNEL_REAR_RIGHT = 4<br />
OGG_CHANNEL_LFE_CENTER = 5<br />
OGG_CHANNEL_LFE_LEFT = 6<br />
OGG_CHANNEL_LFE_RIGHT = 7<br />
<br />
This leaves two ways to define a stereo file:<br />
<br />
channel_type = OGG_CHANNEL_MAP_STEREO<br />
channel_map [0] = OGG_CHANNEL_FRONT_LEFT<br />
channel_map [1] = OGG_CHANNEL_FRONT_RIGHT<br />
<br />
or as:<br />
<br />
channel_type = OGG_CHANNEL_MAP_STEREO<br />
channel_map [0] = OGG_CHANNEL_FRONT_RIGHT<br />
channel_map [1] = OGG_CHANNEL_FRONT_LEFT<br />
<br />
==== Channel Conversion Header ====<br />
<br />
Any number of channel conversion headers can be specified. This header specifies how to down-mix the data to another format.<br />
<br />
32 0x00000001 Remixing Header Id<br />
16 [uint] Major version<br />
16 [uint] Minor version<br />
32 [uint] Target Channel type<br />
32xMxN [sint] Target Channel (M) x Src Channel (N) Gain array<br />
<br />
The ordering of the mixing matrix is such that source channel gains are consecutive. The gain (note: *signed* integer) has the 16 MSBs for the integer part (including sign) and 16 bits for the fracional part of the gain. Note: the gain can be negative.<br />
<br />
=== Data Packets ===<br />
<br />
Data packets contain the raw PCM audio in interleaved format (complete frames are encoded sequentially) with the following definitions/restrictions:<br />
<br />
* A PCM "frame" is composed of samples for all channels at a given time.<br />
* Any OggPCM packet MUST only contain complete frames (ie samples for all channels at a given sampling instance). Partial frames are forbidden.<br />
* There is no padding allowed in a frame except when some bits (<8) are needed to complete a byte. This means that packet size has a direct relationship to the number of frames in the packet (for purposes of seeking).<br />
* Recommended packet size is smaller than 4k since interleaving and seeking in Ogg bitstreams is done on the resolution of packets and thus larger packet sizes create suboptimal bitstreams.<br />
<br />
=== Supported PCM Formats ===<br />
<br />
Format ID Short Name Description<br />
-- Integer coding<br />
0x00000000 OGGPCM_FMT_S8 Signed integer 8 bit<br />
0x00000001 OGGPCM_FMT_U8 Unsigned integer 8 bit<br />
0x00000002 OGGPCM_FMT_S16_LE Signed integer 16 bit little endian<br />
0x00000003 OGGPCM_FMT_S16_BE Signed integer 16 bit big endian<br />
0x00000004 OGGPCM_FMT_S24_LE Signed integer 24 bit little endian<br />
0x00000005 OGGPCM_FMT_S24_BE Signed integer 24 bit big endian<br />
0x00000006 OGGPCM_FMT_S32_LE Signed integer 32 bit little endian<br />
0x00000007 OGGPCM_FMT_S32_BE Signed integer 32 bit big endian<br />
--<br />
-- Compressed PCM<br />
0x00000010 OGGPCM_FMT_ULAW G.711 u-law encoding (8 bit)<br />
0x00000011 OGGPCM_FMT_ALAW G.711 A-law encoding (8 bit)<br />
--<br />
-- IEEE Floating point coding<br />
0x00000020 OGGPCM_FMT_FLT32_LE IEEE Float [-1,1] 32 bit little endian<br />
0x00000021 OGGPCM_FMT_FLT32_BE IEEE Float [-1,1] 32 bit big endian<br />
0x00000022 OGGPCM_FMT_FLT64_LE IEEE Float [-1,1] 64 bit little endian<br />
0x00000023 OGGPCM_FMT_FLT64_BE IEEE Float [-1,1] 64 bit big endian<br />
<br />
Format IDs below 0x80000000 are reserved for use by Xiph and all the ones above are allowed for application-specific formats.<br />
<br />
=== Format Defaults ===<br />
<br />
(ideas by JMV, not yet approved by anyone else. Should be merged in respective header definition above if approved)<br />
<br />
In order to simplify implementations when it comes to channel mappings, several defaults are defined when no extra header is present.<br />
<br />
==== Channel Encoding ====<br />
<br />
* Files containing one channel are assumed to be plain mono files with:<br />
channel_type = OGG_CHANNEL_MAP_MONO<br />
channel_map [0] = OGG_CHANNEL_FRONT_CENTER<br />
<br />
* Files containing two channels are assumed to be stereo files with:<br />
channel_type = OGG_CHANNEL_MAP_STEREO<br />
channel_map [0] = OGG_CHANNEL_FRONT_LEFT<br />
channel_map [1] = OGG_CHANNEL_FRONT_RIGHT<br />
<br />
* Files containing four channels are assumed to be quadraphonic files with:<br />
channel_type = OGG_CHANNEL_MAP_QUADROPHONIC<br />
channel_map [0] = OGG_CHANNEL_FRONT_LEFT<br />
channel_map [1] = OGG_CHANNEL_FRONT_RIGHT<br />
channel_map [2] = OGG_CHANNEL_REAR_LEFT<br />
channel_map [3] = OGG_CHANNEL_REAR_RIGHT<br />
<br />
==== Channel Conversion ====<br />
<br />
* Stereo files SHOULD be converted to mono files by averaging the left channel and the right channel<br />
* Quadraphonic files SHOULD be converted to stereo files by averaging the corresponding rear and front channels.<br />
<br />
== Related Links ==<br />
Short info about AC-3: http://www.mediatwins.com/en/support/kb_topic_11.html<br />
<br />
AC-3 spec: http://www.atsc.org/standards/a_52a.pdf <br><br />
Note: around p34/140 it appears to be how the channel mapping is encoded.<br />
<br />
.wav extended headers for multi channel: http://www.microsoft.com/whdc/device/audio/multichaud.mspx<br />
<br />
General surround info: http://www.surroundassociates.com/fqmain.html</div>Gumboothttps://wiki.xiph.org/index.php?title=XiphWiki:Sandbox&diff=2120XiphWiki:Sandbox2005-11-17T16:20:03Z<p>Gumboot: revert spam</p>
<hr />
<div>= Headline 1 =<br />
== Headline 2 ==<br />
=== Headline 3 ===<br />
=== Headline 4 ===<br />
{| border=2 cellpadding=10<br />
|+ '''Table test'''<br />
| x || 'One' || ''Two2'' || '''Three'''<br />
|-<br />
! what is this<br />
| 'yes' <br />
| ''no'' <br />
! maybe<br />
|-<br />
!<br />
{| border=1 cellpadding =2<br />
|+ for you<br />
| a<br />
| b<br />
| c<br />
|-<br />
| d || e|| f<br />
|}<br />
| 1 || 2 || 3<br />
|}<br />
<br />
This is a good test<br />
<br />
== Headline 5 ==<br />
<br />
* Item 1<br />
* Item 2<br />
* Item 3<br />
<br />
<br />
LoSSSSSSSSSSSSSSSSSSSSSSSSSSSSSStus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.<br />
<br />
Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.<br />
<br />
Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.<br />
<br />
It has been reported that links to ".com" sites don't work: [http://www.vorbis.com/ Vorbis Website]<br />
<br />
== Headline 2 ==<br />
Good goodess, don't you hate wiki spam?</div>Gumboothttps://wiki.xiph.org/index.php?title=OggPCM_Draft3&diff=2118OggPCM Draft32005-11-17T10:34:15Z<p>Gumboot: /* Supported PCM Formats */ Excel and IBM mainframe compatability</p>
<hr />
<div>'''Just in case it's not obvious, this page is just meant to be funny. Don't take this as a spec.'''<br />
<br />
== Alternate format for OggPCM ==<br />
<br />
=== Main Header Packet ===<br />
Multi-bit fields in the header packets are packed in big indian order, to be consistent with network bit order. Bits MUST NOT be spread on both sides of a bit boundary as cutting bits in half is too CPU intensive, especially the zeros.<br />
<br />
A header packet contains the following fields: <br />
<br />
1 0 Codec identifier. Please make sure no other format starts with a bit set to zero.<br />
16 0x00 Version Major (increment and have fun breaking other people's applications)<br />
16 0x00 Version Minor (should be compatible, try being more creative as to how to break stuff)<br />
32 [uint] PCM format<br />
32 [uint] Phase of the moon<br />
32 [uint] Sampling rate in ROT13 format<br />
32 [uint] Number of Channels (please make use of all the bits here)<br />
16 [uint] Number of flames since creation of the spec (if 16 bits aren't enough, steel from next field)<br />
16 [uint] Number of developers implementing the spec (number will go down as previous field increases)<br />
32 [uint] Favorite colour (RGBA)<br />
1 [bool] Evil bit. Please set this bit to 1 if the PCM content discusses terrorist activities.<br />
1 [bool] Clueless bit. Please set this bit to 1 if you don't know what to set it to.<br />
1 [bool] Wiretap bit. If you are wiretapping stream content. Please alter this bit in the transmission.<br />
1 [bool] Steganography bit. If set to 1, undetectable information is encoded in the samples LSB.<br />
16 [uint] Annoyance field. Rate annoyance of the content from 0 to 65535.<br />
128 [uint] Magic number. Enter the right magic number or else I won't play your file.<br />
8x12[char] CC field. Please leave your credit number here.<br />
<br />
Decoder implementations SHOULD refrain from making use of the CC field for online shopping purposes.<br />
<br />
=== Comment packet ===<br />
<br />
Please rate whether you are satisfied with the spec (1: completely unsatisfied, 5: completely satisfied). Format is ASCII (1 char)<br />
<br />
=== Extra Headers (optional) ===<br />
<br />
Extra header packets contain additional information about the OggPCM stream. Each extra header is defined as:<br />
<br />
32 [uint] Header ID<br />
... Header data<br />
<br />
==== Astrological Header ====<br />
<br />
The channel mapping header is defined as:<br />
<br />
32 0x00000000 Header ID<br />
16 [uint] Major version<br />
16 [uint] Minor version<br />
32 [uint] Phase of the moon (0 if unchanged from main header)<br />
32 [unit] Position of Venus<br />
<br />
==== Encryption Header ====<br />
<br />
OggPCM supports advanced DRM features. The encryption information is defined as:<br />
<br />
32 0x00000000 Header ID (we use the same as the Astrological Header, they're interchangeable)<br />
24 [uint] ROT13 Key (ROT13 version of the string "KEY")<br />
<br />
Note that unauthorized decoding of the ROT13 key is a criminal offense under the DMCA (or your country's equivalent law).<br />
<br />
=== Data Packets ===<br />
<br />
Data packets contain either raw or cooked PCM audio in interleaved format:<br />
<br />
* A PCM "frame" is composed of samples for all channels of all songs at a given time.<br />
* Partial frames are forbidden. Offending frames '''will''' be prosecuted.<br />
* Recommended packet size is smaller than 4 TBytes.<br />
<br />
In cases of encrypted streams, each 24-bit sequence in the data packet is XORed with the ROT13 Key. The XOR operation is performed twice (using the same key) for additional security.<br />
<br />
=== Supported PCM Formats ===<br />
<br />
Format ID Short Name Description<br />
-- Integer coding<br />
0x00000000 OGGPCM_FMT_S8 Signed integer 8 bit<br />
0x00000001 OGGPCM_FMT_U8 Unsigned integer 8 bit<br />
0x00000002 OGGPCM_FMT_S16_LE Signed integer 16 bit little endian<br />
0x00000003 OGGPCM_FMT_S16_BE Signed integer 16 bit big endian<br />
--<br />
0x00000004 OGGPCM_FMT_ASCII Whitespace-separated ASCII<br />
0x000000G4 OGGPCM_FMT_EBCDIC Whitespace-separated EBCDIC<br />
0x000000H4 OGGPCM_FMT_ASCII_CSV Comma-separated ASCII<br />
0x000000I4 OGGPCM_FMT_EBCDIC_CSV Comma-separated EBCDIC<br />
0x00000005 OGGPCM_FMT_S16_ROT13_LE ROT13 Signed integer 16 bit little endian<br />
0x00000006 OGGPCM_FMT_S16_ROT26_LE ROT26 Signed integer 16 bit little endian<br />
0x00000007 OGGPCM_FMT_S16_RAND_LE Signed integer 16 bit little endian with random bit order<br />
--<br />
0x00000008 OGGPCM_FMT_FLOAT32_LE IEEE 32-bit float, little endian [-inf,+inf]<br />
0x000000G8 OGGPCM_FMT_FLOAT32_LE_SPIN IEEE 32-bit float, little endian, source sampled with spintronics technology [-inf,+inf]<br />
<br />
0x00000009 OGGPCM_FMT_FLOAT32_ME IEEE 32-bit float, machine endian [-inf,+inf]<br />
0x000000010 OGGPCM_FMT_FLOAT32_RME IEEE 32-bit float, remote machine endian [-inf,+inf]<br />
<br />
0x0000000A OGGPCM_FMT_FLOAT64_LE IEEE double precision float, little endian [-inf,+inf]<br />
0x0000000B OGGPCM_FMT_FLOAT96_LE IEEE triple precision float, little endian [-inf,+inf]<br />
0x0000000C OGGPCM_FMT_FLOAT_MSB_LE IEEE mine's-bigger-than-yours precision float, little endian [-inf,+inf]<br />
0x0000000E OGGPCM_FMT_FLOAT_INF_LE IEEE infinite precision float, little endian [-inf,+inf]<br />
0x0000000F OGGPCM_FMT_FLOAT_INF1_LE IEEE infinity-plus-one precision float, little endian [-inf,+inf]<br />
<br />
Float formats use linear scaling from -inf to +inf. It is part of the speficication that a float value of NaN MUST result in the destruction of the galaxy or (as a minimum) our galaxy. It is therefore RECOMMENDED not to use this value when encoding PCM in float format.</div>Gumboothttps://wiki.xiph.org/index.php?title=Main_Page&diff=2089Main Page2005-11-13T14:18:09Z<p>Gumboot: revert spam</p>
<hr />
<div>= Projects/Formats =<br />
<br />
In an effort to bring open-source ideals to the world of multimedia The Xiph.org Foundation ([[XiphOrg]]) develops a multitude of amazing products. <br />
<br />
== Container Formats ==<br />
<br />
* [[Ogg]]: Media container. This is our native format and the recommeded container for Xiph codecs.<br />
* [[OggSkeleton]]: Skeleton information on all logical content bitstreams in Ogg<br />
<br />
* [[SpeexRTP]]: RTP payload format for voice<br />
* [[VorbisRTP]]: RTP payload format for general audio<br />
* [[TheoraRTP]]: RTP payload format for video<br />
* [[XSPF]]: XML playlist format<br />
<br />
== Codecs ==<br />
* '''Compressed Codecs:'''<br />
** [[Vorbis]]: Audio codec with a [[Tremor|fixed point decoder]]<br />
** [[Theora]]: Video codec<br />
** [[FLAC]]: Free Lossless Audio Codec<br />
** [[Speex]]: Speech codec<br />
** [[OggMNG]]: A mapping for encapsulating the MNG animation format in Ogg<br />
* '''[[RawCodecs|Uncompressed Codecs]]:'''<br />
** [[OggPCM]]: Uncompressed PCM audio, primarily as an interchange codec<br />
** [[OggRGB]]: Uncompressed RGB video, primarily as an interchange codec<br />
** [[OggYUV]]: Uncompressed YUV video, primarily as an interchange codec, undergoing heavy debate<br />
** [[OggWrit]]: Text phrase codec (e.g. subtitles)<br />
* '''Metadata Codecs:'''<br />
** [[Metadata]]: Arbitrary metadata stream format (vapourware so far)<br />
<br />
== Software for distributing media ==<br />
<br />
* [[Icecast]]: Streaming server<br />
* [[Ices]]: Source client for Icecast servers<br />
* [[IceShare]]: P2P content distribution<br />
<br />
== Other software ==<br />
<br />
* [[OggComponent/VorbisComponent]]: Wrappers to integrate Ogg-Vorbis into MacOsX<br />
<br />
= Demonstrations =<br />
<br />
Want to hear Xiph in action? These projects are using our codecs, formats, or libraries.<br />
<br />
* [[VorbisStreams]]: Stations streaming with the Vorbis codec<br />
* [[Games that use Vorbis]]: Games using the Vorbis codec for music or sound effects<br />
* [[VorbisHardware]]: Hardware players using the Vorbis codec<br />
* [http://www.tversity.com TVersity Media Server]: A UPNP/AV compliant media server that uses the Ogg Vorbis libraries to transcode audio files to the Ogg Vorbis format.<br />
<br />
= Project management =<br />
<br />
* [[MonthlyMeeting]]<br />
* [[MailingLists]]<br />
* [[Bounties]]<br />
* [[HyperFish]]<br />
<br />
= Wiki internal =<br />
* [[Sandbox]]: Testbed for testing editing skills.<br />
* [[Translations]]: What about some translation work</div>Gumboothttps://wiki.xiph.org/index.php?title=Main_Page&diff=2040Main Page2005-11-13T13:19:38Z<p>Gumboot: revert spam</p>
<hr />
<div>= Projects/Formats =<br />
<br />
In an effort to bring open-source ideals to the world of multimedia The Xiph.org Foundation ([[XiphOrg]]) develops a multitude of amazing products. <br />
<br />
== Container Formats ==<br />
<br />
* [[Ogg]]: Media container. This is our native format and the recommeded container for Xiph codecs.<br />
* [[OggSkeleton]]: Skeleton information on all logical content bitstreams in Ogg<br />
<br />
* [[SpeexRTP]]: RTP payload format for voice<br />
* [[VorbisRTP]]: RTP payload format for general audio<br />
* [[TheoraRTP]]: RTP payload format for video<br />
* [[XSPF]]: XML playlist format<br />
<br />
== Codecs ==<br />
* '''Compressed Codecs:'''<br />
** [[Vorbis]]: Audio codec with a [[Tremor|fixed point decoder]]<br />
** [[Theora]]: Video codec<br />
** [[FLAC]]: Free Lossless Audio Codec<br />
** [[Speex]]: Speech codec<br />
** [[OggMNG]]: A mapping for encapsulating the MNG animation format in Ogg<br />
* '''[[RawCodecs|Uncompressed Codecs]]:'''<br />
** [[OggPCM]]: Uncompressed PCM audio, primarily as an interchange codec<br />
** [[OggRGB]]: Uncompressed RGB video, primarily as an interchange codec<br />
** [[OggYUV]]: Uncompressed YUV video, primarily as an interchange codec, undergoing heavy debate<br />
** [[OggWrit]]: Text phrase codec (e.g. subtitles)<br />
* '''Metadata Codecs:'''<br />
** [[Metadata]]: Arbitrary metadata stream format (vapourware so far)<br />
<br />
== Software for distributing media ==<br />
<br />
* [[Icecast]]: Streaming server<br />
* [[Ices]]: Source client for Icecast servers<br />
* [[IceShare]]: P2P content distribution<br />
<br />
== Other software ==<br />
<br />
* [[OggComponent/VorbisComponent]]: Wrappers to integrate Ogg-Vorbis into MacOsX<br />
<br />
= Demonstrations =<br />
<br />
Want to hear Xiph in action? These projects are using our codecs, formats, or libraries.<br />
<br />
* [[VorbisStreams]]: Stations streaming with the Vorbis codec<br />
* [[Games that use Vorbis]]: Games using the Vorbis codec for music or sound effects<br />
* [[VorbisHardware]]: Hardware players using the Vorbis codec<br />
* [http://www.tversity.com TVersity Media Server]: A UPNP/AV compliant media server that uses the Ogg Vorbis libraries to transcode audio files to the Ogg Vorbis format.<br />
<br />
= Project management =<br />
<br />
* [[MonthlyMeeting]]<br />
* [[MailingLists]]<br />
* [[Bounties]]<br />
* [[HyperFish]]<br />
<br />
= Wiki internal =<br />
* [[Sandbox]]: Testbed for testing editing skills.<br />
* [[Translations]]: What about some translation work</div>Gumboothttps://wiki.xiph.org/index.php?title=OggPCM_Draft1&diff=2037OggPCM Draft12005-11-12T15:37:47Z<p>Gumboot: /* What is it */ Prefer InterWiki syntax</p>
<hr />
<div>== What is it ==<br />
<br />
'''OggPCM''' is a pulse-code modulation (PCM) audio codec for Ogg. Similar to Microsoft's .wav or Apple's .aiff formats, it's a simple way to store and transfer uncompressed audio within an Ogg container. For the purposes of this document, the term PCM is used to describe a digital representation of an audio signal, where volume samples are taken at regular uniform intervals and then quantized into a digital (usually binary) code. A more complete definition of PCM and related terminology can be found at [[Wikipedia:Pulse-code_modulation|Wikipedia]].<br />
<br />
== Why is it ==<br />
The intention for this format is as an interchange format, for example for use with [[OggStream]]. It is also useful for storing time-synced decoded audio/video, as opposed to using RIFF/WAV (.wav) and YUV4MPEG (.yuv) in separate files as was done during [[Theora]] development. It is intended to be less complex to use than either RIFF or AIFF<br />
<br />
The degenerate stream is a single header packet followed by the raw data packets. While this degenerate stream is not incredibly useful for long term storage or as a general purpose container, it is useful for applications where other data describing the stream is available out of band, for instance amongst cooperating applications in an inter-process communication scheme. Streams providing the extra defined comment packets are intended to be useful for long term storage and communication amongst diverse applications.<br />
<br />
== Format ==<br />
<br />
'' This is a the current working draft, a compromise between the different promposed elements needed ''<br />
<br />
Packets are processed as per the value of their first byte. Packets of unknown ID should be silently ignored, providing a convient way to add future expandability which does not break the data format. Multibyte fields in the header packets are packed in little endian order. Multibyte fields in the data packet are packed according to the endian flag in the stream header packet.<br />
<br />
An audio frame consists of one sample from each audio channel encoded in sequence. The granule position specified is the total audio frames in the stream including the last complete packet in a page. Audio frames must not be split across packets. The rationale here is that the position specified in the frame header of the last page tells how long the data coded by the bitstream is in samples as well as provides the current stream position to seeking routines. A truncated stream will still return the proper number of audio frames that can be decoded fully.<br />
<br />
An example of how this can be useful is the proposed ReplayGain extension to .wav format: http://replaygain.hydrogenaudio.org/file_format_wav.html<br />
<br />
Note that no such extension is planned, nor is the need for a future format forseen, but history has shown that even the most basic formats eventually become obsolete.<br />
<br />
Packet 0, BOS, 12 bytes<br />
8 0x00 Stream Header Packet ID<br />
24 "PCM" Codec identifier <br />
-<br />
8 0x01 Version Major (breaks backwards compatability to increment)<br />
8 0x00 Version Minor (backwards compatable, ie, via extended header)<br />
8 [int] Number of Channels (1-256)<br />
1 [flg] False = MSB, True = LSB<br />
3 [int] PCM Data Type (see table below)<br />
4 [nil] Padding to byte, may be used in later minor version<br />
-<br />
32 [int] Samplerate (samples/second)<br />
<br />
Comment Header Packet<br />
8 0x03 Comment Header Packet ID<br />
24 "PCM" Codec Identifier<br />
-- Continues as [[http://www.xiph.org/vorbis/doc/Vorbis_I_spec.html#vorbis-spec-comment|Vorbis's Comment Header]]<br />
<br />
Data Packet<br />
8 0xFF Data Packet ID<br />
24 "PCM" Codec identifier, pads data to 32-bits<br />
.. [data] variable length pcm data<br />
<br />
PCM Data Type<br />
=============<br />
ID# Bits Type<br />
0 8 signed (char)<br />
1 8 unsigned (char)<br />
2 16 signed (short int)<br />
3 24 signed (int + 8bit padding)<br />
4 32 signed (int)<br />
5 32 float (float)<br />
6 64 float (double)<br />
7 ? Extended unsupported by 1.0 software<br />
<br />
'''Encapsulation in Ogg'''<br />
<br />
The granulepos of an Ogg page indicates the presentation time of the last presentable element in the last complete packet within that page; for '''OggPCM''', a granule is an audio frame.<br />
<br />
Following standard terminology for uncompressed audio, an audio frame is the collection of samples for all channels for a single sampling period. For example, an audio frame for a stereo signal is a pair of sample values for the left and right channels.<br />
<br />
'''Constraints'''<br />
<br />
* Version 1.0 codec software MUST NOT attempt to decode when the Extended (7) Data Type is specified.<br />
<br />
* An OggPCM packet MUST NOT be constructed with a partial frame; ie. an audio frame must not span two Ogg packets.<br />
<br />
== Alternative Format ==<br />
<br />
''This format was written by [[User:Jkoleszar|Jkoleszar]], and has since been combined with other ideas into the primary format (above)''<br />
<br />
It is intended to support channels from the same source having different sampling parameters.<br />
<br />
'''Packet structure'''<br />
<br />
Packet 0, BOS, tbd bytes<br />
8 0x00 Header Packet ID<br />
24 "PCM" Codec identifier <br />
-<br />
8 0x01 Version Major (breaks backwards compatability to increment)<br />
8 0x00 Version Minor (backwards compatable, ie, via extended header)<br />
8 [uint] Source ID (Unique amongst all OggPCM streams in the physical stream)<br />
8 [uint] Channel Block<br />
-<br />
16 [bitfield] Indicates which of the 16 channels in this channel block <br />
are present in this logical OGGPCM stream.<br />
8 [enum] Sample format (OGGPCM_FMT_U8, OGGPCM_FMT_LE_S16, OGGPCM_FMT_BE_S16, etc) <br />
24 [uint] Sample rate ** this field crosses a 32bit-word barrier ** <br />
<br />
Data Packet<br />
8 0xFF Data Packet ID<br />
24 "PCM" Codec identifier, pads data to 32-bits<br />
.. [data] variable length pcm data, packing defined by Sample Format field in header<br />
<br />
'''Sample Format'''<br />
<br />
OGG_PCM_S8 = 0x1 /* Signed 8 bit. */<br />
OGG_PCM_S16 = 0x2<br />
OGG_PCM_S24 = 0x3<br />
OGG_PCM_S32 = 0x4<br />
OGG_PCM_U8 = 0x5 /* Unsigned 8 bit */<br />
OGG_PCM_FLOAT32 = 0x6<br />
OGG_PCM_FLOAT64 = 0x7<br />
<br />
<br />
<br />
'''Discussion'''<br />
<br />
This seems to make it easy to support the simple/normal cases and possible to support the pathological cases, for instance:<br />
{| border="1" cellpadding="1"<br />
| Source ID || Channel Bitfield || Sample Rate || Sample Format || Comment<br />
|-<br />
| 0x00 || 0000 0000 0000 0011 || 96000 || OGGPCM_FMT_LE_S24 || Front Stereo Pair<br />
|-<br />
| 0x00 || 0000 0000 0011 1100 || 44100 || OGGPCM_FMT_LE_S16 || Center And Surrounds<br />
|-<br />
| 0x00 || 0000 0000 0010 0000 || 8000 || OGGPCM_FMT_LE_S16 || LFE Channel<br />
|-<br />
| 0x01 || 0000 0000 0000 0001 || 8000 || OGGPCM_FMT_U8 || PC Speaker<br />
|-<br />
| 0x02 || 0000 0000 0000 0001 || 8000 || OGGPCM_FMT_U8 || Microphone<br />
|-<br />
| 0x03 || 0000 0000 0000 0011 || 8000 || OGGPCM_FMT_LE_S16 || Voice Chat<br />
|}<br />
<br />
Each entry in the table is a logical Ogg stream. [[User:Jkoleszar|Jkoleszar]] is not convinced that the source id and channel block are necessary, but figured he'd throw it out there.</div>Gumboothttps://wiki.xiph.org/index.php?title=Main_Page&diff=2038Main Page2005-11-12T00:41:58Z<p>Gumboot: revert spam</p>
<hr />
<div>= Projects/Formats =<br />
<br />
In an effort to bring open-source ideals to the world of multimedia The Xiph.org Foundation ([[XiphOrg]]) develops a multitude of amazing products. <br />
<br />
== Container Formats ==<br />
<br />
* [[Ogg]]: Media container. This is our native format and the recommeded container for Xiph codecs.<br />
* [[OggSkeleton]]: Skeleton information on all logical content bitstreams in Ogg<br />
<br />
* [[SpeexRTP]]: RTP payload format for voice<br />
* [[VorbisRTP]]: RTP payload format for general audio<br />
* [[TheoraRTP]]: RTP payload format for video<br />
* [[XSPF]]: XML playlist format<br />
<br />
== Codecs ==<br />
* '''Compressed Codecs:'''<br />
** [[Vorbis]]: Audio codec with a [[Tremor|fixed point decoder]]<br />
** [[Theora]]: Video codec<br />
** [[FLAC]]: Free Lossless Audio Codec<br />
** [[Speex]]: Speech codec<br />
** [[OggMNG]]: A mapping for encapsulating the MNG animation format in Ogg<br />
* '''[[RawCodecs|Uncompressed Codecs]]:'''<br />
** [[OggPCM]]: Uncompressed PCM audio, primarily as an interchange codec<br />
** [[OggRGB]]: Uncompressed RGB video, primarily as an interchange codec<br />
** [[OggYUV]]: Uncompressed YUV video, primarily as an interchange codec, undergoing heavy debate<br />
** [[OggWrit]]: Text phrase codec (e.g. subtitles)<br />
* '''Metadata Codecs:'''<br />
** [[Metadata]]: Arbitrary metadata stream format (vapourware so far)<br />
<br />
== Software for distributing media ==<br />
<br />
* [[Icecast]]: Streaming server<br />
* [[Ices]]: Source client for Icecast servers<br />
* [[IceShare]]: P2P content distribution<br />
<br />
== Other software ==<br />
<br />
* [[OggComponent/VorbisComponent]]: Wrappers to integrate Ogg-Vorbis into MacOsX<br />
<br />
= Demonstrations =<br />
<br />
Want to hear Xiph in action? These projects are using our codecs, formats, or libraries.<br />
<br />
* [[VorbisStreams]]: Stations streaming with the Vorbis codec<br />
* [[Games that use Vorbis]]: Games using the Vorbis codec for music or sound effects<br />
* [[VorbisHardware]]: Hardware players using the Vorbis codec<br />
* [http://www.tversity.com TVersity Media Server]: A UPNP/AV compliant media server that uses the Ogg Vorbis libraries to transcode audio files to the Ogg Vorbis format.<br />
<br />
= Project management =<br />
<br />
* [[MonthlyMeeting]]<br />
* [[MailingLists]]<br />
* [[Bounties]]<br />
* [[HyperFish]]<br />
<br />
= Wiki internal =<br />
* [[Sandbox]]: Testbed for testing editing skills.<br />
* [[Translations]]: What about some translation work</div>Gumboothttps://wiki.xiph.org/index.php?title=Talk:OggYUV&diff=1987Talk:OggYUV2005-11-10T10:58:03Z<p>Gumboot: /* Chroma Subsampling Methods */</p>
<hr />
<div>=== Interlace Flag? ===<br />
* The interlacing information doesn't seem complete to me. How do you know which field(s) you have in any give packet, for example? How do you distinguish between a 25Hz shutter and a 50Hz shutter? Field order switching? Mixing with uninterlaced data?<br />
--[[User:Gumboot|Gumboot]] 03:00, 9 Nov 2005 (PST)<br />
<br />
* In my experience, all interlace is every other frame, even scanlines followed by odd scanlines. Is there any video codec which supports more than an interlace flag? <br />
--[[User:Arc|Arc]] 10:42, 9 Nov 2005 (PST)<br />
<br />
<br />
=== Variable frame-rates ===<br />
* There doesn't seem to be any handling of variable frame-rate data, or a specification for a timebase for the granulepos.<br />
--[[User:Gumboot|Gumboot]] 03:00, 9 Nov 2005 (PST)<br />
<br />
* Granulepos is the last frame decodable in the current packet/page. As far as variable framerates within a single stream, is there any codec which supports this currently? <br />
--[[User:Arc|Arc]] 10:42, 9 Nov 2005 (PST)<br />
<br />
<br />
=== Codec Identifier ===<br />
* The identifier seems a little short. You'd get false positives if somebody wanted to use a "YUVx" format, for example.<br />
--[[User:Gumboot|Gumboot]] 03:00, 9 Nov 2005 (PST)<br />
<br />
* I believe that's OK with raw formats, if someone wanted to use a YUV-like codec they could use a prefix, vs a suffix, to identify it by. Also, if their header packet ID is something other than 0x00, it will not generate a false positive to have a YUV* codec identifier since the YUV plugins only support streams which begin with packet id 0. <br />
--[[User:Arc|Arc]] 10:42, 9 Nov 2005 (PST)<br />
<br />
<br />
=== Aspect ratio ===<br />
* Is the aspect ratio the pixel aspect or the frame aspect? <br />
--[[User:Gumboot|Gumboot]] 03:00, 9 Nov 2005 (PST)<br />
<br />
* Frame aspect, this acts exactly like the aspect ratio in the Theora header, right down to having the same bit-size for the fields. Typically, the ratio is 4:3 or 16:9. <br />
--[[User:Arc|Arc]] 10:42, 9 Nov 2005 (PST)<br />
<br />
<br />
=== Chroma Subsampling Methods ===<br />
* We need to know two things, what the size/shape of chroma pixels are, and if they are packed, what order they are provided in the bitstream.<br />
** This seperates the order of the data and the processing of the data, both of which are important but get very complicated if mixed<br />
** The order must match the shape it's based on, ie, 4:4:4 should be in "0:0" order, any other value (which is illegal) should not be supported by any software if encountered and should never be generated.<br />
<br />
Chroma Pixel "Shapes"<br />
=====================<br />
ID Shape Used-In<br />
0 #--- 4:4:4<br />
----<br />
----<br />
----<br />
.<br />
1 ##-- 4:2:2<br />
----<br />
---- <br />
----<br />
.<br />
2 #### 4:1:1<br />
----<br />
----<br />
----<br />
.<br />
3 #--- ?<br />
#---<br />
----<br />
----<br />
.<br />
4 ##-- 4:2:0<br />
##--<br />
----<br />
----<br />
.<br />
5 #### 4:1:0<br />
####<br />
----<br />
----<br />
.<br />
6 #### ?<br />
####<br />
####<br />
####<br />
.<br />
7 Extended Shape, unsupported in v1.0<br />
<br />
* In things like 420 you also need to know the relative phase of the sampling of the chroma. Some standards have it as being sampled exactly on the top left, some halfway across the top row, some halfway down the left edge, some in the centre of everything... then there are all the interlaced variants.<br />
: You also have the matter of whether or not there are unused areas at the top and bottom of the range of legal values, and many other things along those lines.<br />
--[[User:Gumboot|Gumboot]] 02:58, 10 Nov 2005 (PST)</div>Gumboothttps://wiki.xiph.org/index.php?title=Talk:OggPCM_Draft1&diff=1991Talk:OggPCM Draft12005-11-10T10:08:58Z<p>Gumboot: /* Do we need to record int/float data flag? */</p>
<hr />
<div>=== Do we need signed/unsigned data flag? ===<br />
<br />
* Not really. The data can be easily changed to signed as default losslessly. Unsigned 8-bit data (where 128 is the median) is easily changed to signed, and changed back if being saved as RIFF/WAV (which only supports unsigned 8-bit). However, it wouldn't hurt to support it. Applications can be built to support one or multiple formats, thus requesting conversion if not supported by the codec. <br />
--[[User:Arc|Arc]]<br />
<br />
* I don't agree with that. It just puts more conditional code into packages that would normally have only one native format and it gives them more opportunity to fail to support variants of the format. If it's fixed then a few packages will always have to modify the data, and most will never get it wrong. If it's variable then every package will have to do something sometimes, or fail occasionally. <br />
--[[User:Gumboot|Gumboot]] 01:28, 8 Nov 2005 (PST)<br />
<br />
* I see no reason to support any unsigned PCM format other than 8 bit. For instance, I know of no container format which supports unsigned 16 bit.<br />
--[[User:Erikd|Erikd]]<br />
<br />
=== Do we need to record int/float data flag? ===<br />
<br />
* Some codecs (Vorbis) use floating point samples natively. Others only support int. Support for int/float data flag is thus important. <br />
--[[User:Arc|Arc]]<br />
<br />
* Please don't make determination of the data format depend on multiple fields. Instead use an enumeration so that something like little endian 16 bit PCM can be specifed as OGG_PCM_LE_PCM_16 and big endian 16 bit doubles can be specified as OGG_PCM_BE_FLOAT_64. This scheme is far more transparent and self documenting. If the format field is 8 bits, this scheme supports 256 formats; if its 16 bit it will support 65536 formats.<br />
<br />
I also suggest leaving the format associated with a value of zero as an invalid format.<br />
--[[Erikd|Erikd]]<br />
* It would ''not'' support 256 formats. It would support the small set of formats that somebody bothered to define early on, and it would not be able to expand because many implementations would fail to follow the changing specification thereby forcing everybody to limit themselves to the initial set.<br />
--[[User:Gumboot|Gumboot]] 02:08, 10 Nov 2005 (PST)<br />
<br />
=== Do we need to offer endian data flag? If not, which is used? ===<br />
<br />
* LSB/MSB can be changed losslessly, one should probobally be settled on for the data and stick with it. It's a fairly low-CPU process to change the endian on the application side in any event, and if the application uses the bitpacker, this isn't even an issue. Supporting both is possible, too, but adds complexity to a format intended to be ''simple''. <br />
--[[User:Arc|Arc]]<br />
<br />
* We should just standardize on little endian ordering for the data. It's commonly used and well supported in hardware and software. Any cross architecture application that can deal WAV's will already know how to support it. <br />
--[[User:Jkoleszar|Jkoleszar]] 11:48, 9 Nov 2005 (PST)<br />
<br />
* I agree that we should use little endian as standard, however, I'm questioning if big endian should be supported as well... after all, it'd be trivial for a plugin to convert from one to another. <br />
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)<br />
<br />
* Big and little endian data formats should both be supported with equal status. There should not even be a default; the endian-ness should be explicit.<br />
--[[User:Erikd|Erikd]]<br />
<br />
=== Is it worth supporting a vorbiscomment header? ===<br />
<br />
* It'd be useful to be able to carry information like what was decoded, or CDDB IDs, or replaygain information. Besides, if you don't put it in then five other people will do it five different ways. <br />
--[[User:Arc|Arc]]<br />
<br />
<br />
=== How does one interpret a file where the Bits per Sample is neither 32 nor 64 and the Data Type is float? ===<br />
* One doesn't. Standardize on IEEE floats and be done with it. Simple, remember? :)<br />
--[[User:Jkoleszar|Jkoleszar]] 11:48, 9 Nov 2005 (PST)<br />
<br />
* I'm uncertain exactly what this question is. Hopefully the submitter can clarify? <br />
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)<br />
<br />
* 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.<br />
--[[Erikd|Erikd]]<br />
<br />
=== Are samples padded to some round number of bits? ===<br />
* I don't know of any PCM formats for non-octet based samples, but if you want to specify something, I'd say pack them into the MSB's of the next larger byte boundary, round toward zero, on a per channel basis. This should allow software that knows how to handle 16 bit audio but not 10 bit to operate on the data.<br />
--[[User:Jkoleszar|Jkoleszar]] 11:48, 9 Nov 2005 (PST)<br />
<br />
* The occurrence of N bit PCM where N is not a multiple of 8 bits is so rare that it should probably be ignored. In addition, there really isn't any reason to treat 10 bit data packed into the 10 most significant bits of a 16 bit int any different from a real 16 bit value. So why make any distinction?<br />
--[[Erikd|Erikd]]<br />
<br />
* 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.<br />
* 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.<br />
--[[User:Gumboot|Gumboot]] 02:02, 10 Nov 2005 (PST)<br />
<br />
== Do we want/need the 32-bit data packet header? ==<br />
* 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]]<br />
<br />
* 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.<br />
--[[User:Jkoleszar|Jkoleszar]] 11:48, 9 Nov 2005 (PST)<br />
<br />
* I believe that 64-bit platforms still use 32-bit memory space (I may be wrong!). Yes, libogg2 buffers should always begin on a 32-bit word boundary, so the beginning of the data should also be on a boundary. This was done intentionally, as was the choice to use a three letter codec identifier for raw codecs (since the packet ID + codec ID = 32bits this way), after an extended IRC discussion on the subject. If ending on a 64-bit boundary is something we're really worried about, we could always add 4 bytes, but I really don't think it should be necessary. <br />
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)<br />
<br />
* On UltraSparc and Alpha CPUs (both 64 bit) accessing a 64 bit double at an address that is not 8 byte aligned causes a segmentation fault. However, accessing unaligned doubles on x86 (ie 32 bit) is slower than accessing aligned doubles. You might want to consider this.<br />
--[[Erikd|Erikd]]</div>Gumboothttps://wiki.xiph.org/index.php?title=Talk:OggPCM_Draft1&diff=1980Talk:OggPCM Draft12005-11-10T10:02:29Z<p>Gumboot: /* Are samples padded to some round number of bits? */</p>
<hr />
<div>=== Do we need signed/unsigned data flag? ===<br />
<br />
* Not really. The data can be easily changed to signed as default losslessly. Unsigned 8-bit data (where 128 is the median) is easily changed to signed, and changed back if being saved as RIFF/WAV (which only supports unsigned 8-bit). However, it wouldn't hurt to support it. Applications can be built to support one or multiple formats, thus requesting conversion if not supported by the codec. <br />
--[[User:Arc|Arc]]<br />
<br />
* I don't agree with that. It just puts more conditional code into packages that would normally have only one native format and it gives them more opportunity to fail to support variants of the format. If it's fixed then a few packages will always have to modify the data, and most will never get it wrong. If it's variable then every package will have to do something sometimes, or fail occasionally. <br />
--[[User:Gumboot|Gumboot]] 01:28, 8 Nov 2005 (PST)<br />
<br />
* I see no reason to support any unsigned PCM format other than 8 bit. For instance, I know of no container format which supports unsigned 16 bit.<br />
--[[User:Erikd|Erikd]]<br />
<br />
=== Do we need to record int/float data flag? ===<br />
<br />
* Some codecs (Vorbis) use floating point samples natively. Others only support int. Support for int/float data flag is thus important. <br />
--[[User:Arc|Arc]]<br />
<br />
* Please don't make determination of the data format depend on multiple fields. Instead use an enumeration so that something like little endian 16 bit PCM can be specifed as OGG_PCM_LE_PCM_16 and big endian 16 bit doubles can be specified as OGG_PCM_BE_FLOAT_64. This scheme is far more transparent and self documenting. If the format field is 8 bits, this scheme supports 256 formats; if its 16 bit it will support 65536 formats.<br />
<br />
I also suggest leaving the format associated with a value of zero as an invalid format.<br />
--[[Erikd|Erikd]]<br />
<br />
=== Do we need to offer endian data flag? If not, which is used? ===<br />
<br />
* LSB/MSB can be changed losslessly, one should probobally be settled on for the data and stick with it. It's a fairly low-CPU process to change the endian on the application side in any event, and if the application uses the bitpacker, this isn't even an issue. Supporting both is possible, too, but adds complexity to a format intended to be ''simple''. <br />
--[[User:Arc|Arc]]<br />
<br />
* We should just standardize on little endian ordering for the data. It's commonly used and well supported in hardware and software. Any cross architecture application that can deal WAV's will already know how to support it. <br />
--[[User:Jkoleszar|Jkoleszar]] 11:48, 9 Nov 2005 (PST)<br />
<br />
* I agree that we should use little endian as standard, however, I'm questioning if big endian should be supported as well... after all, it'd be trivial for a plugin to convert from one to another. <br />
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)<br />
<br />
* Big and little endian data formats should both be supported with equal status. There should not even be a default; the endian-ness should be explicit.<br />
--[[User:Erikd|Erikd]]<br />
<br />
=== Is it worth supporting a vorbiscomment header? ===<br />
<br />
* It'd be useful to be able to carry information like what was decoded, or CDDB IDs, or replaygain information. Besides, if you don't put it in then five other people will do it five different ways. <br />
--[[User:Arc|Arc]]<br />
<br />
<br />
=== How does one interpret a file where the Bits per Sample is neither 32 nor 64 and the Data Type is float? ===<br />
* One doesn't. Standardize on IEEE floats and be done with it. Simple, remember? :)<br />
--[[User:Jkoleszar|Jkoleszar]] 11:48, 9 Nov 2005 (PST)<br />
<br />
* I'm uncertain exactly what this question is. Hopefully the submitter can clarify? <br />
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)<br />
<br />
* 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.<br />
--[[Erikd|Erikd]]<br />
<br />
=== Are samples padded to some round number of bits? ===<br />
* I don't know of any PCM formats for non-octet based samples, but if you want to specify something, I'd say pack them into the MSB's of the next larger byte boundary, round toward zero, on a per channel basis. This should allow software that knows how to handle 16 bit audio but not 10 bit to operate on the data.<br />
--[[User:Jkoleszar|Jkoleszar]] 11:48, 9 Nov 2005 (PST)<br />
<br />
* The occurrence of N bit PCM where N is not a multiple of 8 bits is so rare that it should probably be ignored. In addition, there really isn't any reason to treat 10 bit data packed into the 10 most significant bits of a 16 bit int any different from a real 16 bit value. So why make any distinction?<br />
--[[Erikd|Erikd]]<br />
<br />
* 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.<br />
* 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.<br />
--[[User:Gumboot|Gumboot]] 02:02, 10 Nov 2005 (PST)<br />
<br />
== Do we want/need the 32-bit data packet header? ==<br />
* 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]]<br />
<br />
* 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.<br />
--[[User:Jkoleszar|Jkoleszar]] 11:48, 9 Nov 2005 (PST)<br />
<br />
* I believe that 64-bit platforms still use 32-bit memory space (I may be wrong!). Yes, libogg2 buffers should always begin on a 32-bit word boundary, so the beginning of the data should also be on a boundary. This was done intentionally, as was the choice to use a three letter codec identifier for raw codecs (since the packet ID + codec ID = 32bits this way), after an extended IRC discussion on the subject. If ending on a 64-bit boundary is something we're really worried about, we could always add 4 bytes, but I really don't think it should be necessary. <br />
--[[User:Arc|Arc]] 13:11, 9 Nov 2005 (PST)<br />
<br />
* On UltraSparc and Alpha CPUs (both 64 bit) accessing a 64 bit double at an address that is not 8 byte aligned causes a segmentation fault. However, accessing unaligned doubles on x86 (ie 32 bit) is slower than accessing aligned doubles. You might want to consider this.<br />
--[[Erikd|Erikd]]</div>Gumboothttps://wiki.xiph.org/index.php?title=XiphWiki:Sandbox&diff=2113XiphWiki:Sandbox2005-11-10T09:39:20Z<p>Gumboot: revert spam</p>
<hr />
<div>= Headline 1 =<br />
== Headline 2 ==<br />
=== Headline 3 ===<br />
=== Headline 4 ===<br />
{| border=2 cellpadding=10<br />
|+ '''Table test'''<br />
| x || 'One' || ''Two2'' || '''Three'''<br />
|-<br />
! what is this<br />
| 'yes' <br />
| ''no'' <br />
! maybe<br />
|-<br />
!<br />
{| border=1 cellpadding =2<br />
|+ for you<br />
| a<br />
| b<br />
| c<br />
|-<br />
| d || e|| f<br />
|}<br />
| 1 || 2 || 3<br />
|}<br />
<br />
This is a good test<br />
<br />
== Headline 5 ==<br />
<br />
* Item 1<br />
* Item 2<br />
* Item 3<br />
<br />
<br />
LoSSSSSSSSSSSSSSSSSSSSSSSSSSSSSStus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.<br />
<br />
Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.<br />
<br />
Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.<br />
<br />
It has been reported that links to ".com" sites don't work: [http://www.vorbis.com/ Vorbis Website]<br />
<br />
== Headline 2 ==<br />
Good goodess, don't you hate wiki spam?</div>Gumboothttps://wiki.xiph.org/index.php?title=Talk:OggYUV&diff=1954Talk:OggYUV2005-11-09T11:00:00Z<p>Gumboot: </p>
<hr />
<div>* The interlacing information doesn't seem complete to me. How do you know which field(s) you have in any give packet, for example? How do you distinguish between a 25Hz shutter and a 50Hz shutter? Field order switching? Mixing with uninterlaced data?<br />
* There doesn't seem to be any handling of variable frame-rate data, or a specification for a timebase for the granulepos.<br />
* The identifier seems a little short. You'd get false positives if somebody wanted to use a "YUVx" format, for example.<br />
* Is the aspect ratio the pixel aspect or the frame aspect? --[[User:Gumboot|Gumboot]] 03:00, 9 Nov 2005 (PST)</div>Gumboothttps://wiki.xiph.org/index.php?title=Talk:OggPCM_Draft1&diff=1953Talk:OggPCM Draft12005-11-08T09:28:32Z<p>Gumboot: some kind of formatting</p>
<hr />
<div>'''Do we need signed/unsigned data flag?'''<br />
<br />
Not really. The data can be easily changed to signed as default losslessly. Unsigned 8-bit data (where 128 is the median) is easily changed to signed, and changed back if being saved as RIFF/WAV (which only supports unsigned 8-bit).<br />
<br />
However, it wouldn't hurt to support it. Applications can be built to support one or multiple formats, thus requesting conversion if not supported by the codec.<br />
* I don't agree with that. It just puts more conditional code into packages that would normally have only one native format and it gives them more opportunity to fail to support variants of the format. If it's fixed then a few packages will always have to modify the data, and most will never get it wrong. If it's variable then every package will have to do something sometimes, or fail occasionally. --[[User:Gumboot|Gumboot]] 01:28, 8 Nov 2005 (PST)<br />
<br />
'''Do we need to record int/float data flag?'''<br />
<br />
Some codecs (Vorbis) use floating point samples nativly. Others only support int. Support for int/float data flag is thus important.<br />
<br />
<br />
'''Do we need to offer endian data flag?'''<br />
<br />
LSB/MSB can be changed losslessly, one should probobally be settled on for the data and stick with it. It's a fainly low-CPU process to change the endian on the application side in any event, and if the application uses the bitpacker, this isn't even an issue.<br />
<br />
Supporting both is possible, too, but adds complexity to a format intended to be ''simple''.<br />
<br />
<br />
<br />
'''Which endian is it?'''<br />
<br />
'''Is it worth supporting a vorbiscomment header?'''<br />
<br />
It'd be useful to be able to carry information like what was decoded, or CDDB IDs, or replaygain information. Besides, if you don't put it in then five other people will do it five different ways.<br />
<br />
'''How does one interpret a file where the Bits per Sample is neither 32 nor 64 and the Data Type is float?'''<br />
<br />
'''Are samples padded to some round number of bits?'''</div>Gumboothttps://wiki.xiph.org/index.php?title=Talk:OggPCM_Draft1&diff=1939Talk:OggPCM Draft12005-11-08T09:24:49Z<p>Gumboot: </p>
<hr />
<div>'''Do we need signed/unsigned data flag?'''<br />
<br />
Not really. The data can be easily changed to signed as default losslessly. Unsigned 8-bit data (where 128 is the median) is easily changed to signed, and changed back if being saved as RIFF/WAV (which only supports unsigned 8-bit).<br />
<br />
However, it wouldn't hurt to support it. Applications can be built to support one or multiple formats, thus requesting conversion if not supported by the codec.<br />
<br />
'''Do we need to record int/float data flag?'''<br />
<br />
Some codecs (Vorbis) use floating point samples nativly. Others only support int. Support for int/float data flag is thus important.<br />
<br />
<br />
'''Do we need to offer endian data flag?'''<br />
<br />
LSB/MSB can be changed losslessly, one should probobally be settled on for the data and stick with it. It's a fainly low-CPU process to change the endian on the application side in any event, and if the application uses the bitpacker, this isn't even an issue.<br />
<br />
Supporting both is possible, too, but adds complexity to a format intended to be ''simple''.<br />
<br />
Which endian is it?<br />
Is it worth supporting a vorbiscomment header? It'd be useful to be able to carry information like what was decoded, or CDDB IDs, or replaygain information. Besides, if you don't put it in then five other people will do it five different ways.<br />
How does one interpret a file where the Bits per Sample is neither 32 nor 64 and the Data Type is float?<br />
Are samples padded to some round number of bits?<br />
<br />
I don't agree with the signed/unsigned flag. It just puts more conditional code into packages that would normally have only one native format and it gives them more opportunity to fail to support variants of the format.</div>Gumboothttps://wiki.xiph.org/index.php?title=PortablePlayers&diff=1942PortablePlayers2005-11-08T08:33:35Z<p>Gumboot: revert spam</p>
<hr />
<div>Here you can find all mobile players known to support Ogg [[Vorbis]]. Some do also play FLAC (please add information).<br />
<br />
== Flash Memory Storage ==<br />
<br />
* [http://www.netonnet.se/item.asp?iid=61510 Avant] MP-8256, MP-8512, MP-81000<br />
:Looks like another whitebox label (?) No official website found yet, but three models are offered in shops: MP-8256 with 256MB memory, MP-8512 (512MB) and MP-81000 (1GB). Plays not only Ogg Vorbis, but [[MP3]], [[WMA]] and even JPEG via colour display. <br />
<br />
* [http://enox.co.kr/2004/eng/product/product_830_01.asp ENOX] EMX-830<br />
:'The lightest and the smallest one among AAA type MP3 players.' Supports MP3, WMA, ASF, WAV, and Ogg Vorbis, has FM tuner, line-in and mic with direct MP3 encoding. Comes with 128/256/512/1024MB flash memory and USB 2.0 interface.<br />
<br />
* [http://www.ez-av.com/eng/products/Pd_emp600_01.htm EZAV's] EMP-600, EMP-500, EMP-400<br />
:The EMP-500 is a very light player, comes with 256/512/1024MB storage and supports MP3, WMA, and Ogg Vorbis. The EMP-400 has 256MB storage.<br />
<br />
* [http://eng.iaudio.com/ iAudio] U2, G3, 5<br />
:The iAudio U2 is a small flash-based player (256MB/512MB/1GB) and supports Vorbis. Early U2 releases required a firmware upgrade for Vorbis support; as of September 2005 this support was included in the retail version. The iAudio G3 and iAudio 5 offer up to 2GB, and support Ogg Vorbis out-of-the-box. All three will talk to Linux or Mac (but included s/w is Windows only).<br />
<br />
* [http://www.ibead.co.kr/coding/eng/ i-BEAD] 170, 400<br />
:The i-BEAD 170 & 400 models are small, light flash-based players with built in Lithium-Polymer batteries. They also have OLED displays, and FM & line-in recording. Both are available in 256MB/512MB/1GB and both support Ogg Vorbis after a firmware upgrade.<br />
<br />
* [http://www.iops.co.kr/enghome/index.html Iops] MFP-312, MFP-325, MFP-350<br />
:Iops offers the MFP-300 series player with 128/256/512MB/1GB internal flash memory. They offer voice and FM radio recording whilst maintaining a lightweight portable size.<br />
<br />
* [http://www.iriver.com/ iRiver's] iFP-3xx, iFP-5xx, iFP-7xx, iFP-8xx, iFP-9xx, iFP-10xx, iFP-11xx, T10, T20, U10<br />
:iRiver has a huge line of flash-based players with various memory sizes (128MB to 1GB). Some of these players may need an updated firmware in order to play Ogg Vorbis files, see the [http://www.iriver.com/support/download.asp support download page] for that. Note -- on older players, only certain bitrates are supported, various problems are reported including reboots, silence and random noise when a VBR Vorbis passes outside the limit (96-225 Kbps). Newer players don't have this limitation. However, please be alerted that many of the newer players use weird protocols like MTP so they only work with Windows.<br />
<br />
* [http://www.jensofsweden.com/ Jens Of Sweden's] MP-120, MP-130, MP-400<br />
:The MP-130 is a portable player with flash memory in 128/256/512MB sizes. This appears to be a rebranded Iops player. The MP-400 is a tiny machine with lots of features (line in, mic, fm radio, usb 2.0). With the updated 4.1 firmware it supports Ogg Vorbis files encoded with libvorbis version 1.0rc2 or later. When trying to play files encoded with earlier versions it freezes on playback, requiring an USB connect or reset button pressed (through a tiny hole) to wake up again. The MP-120, a 1Gb flash player, supports Ogg-Vorbis with a firmware upgrade since March 2005. MP-120 still doesn't play old Ogg Vorbis files, but they don't make it freeze up.<br />
<br />
* [http://www.jnc-digital.com/Eng/ JNC's] SSF-2002, SSF-2005<br />
:These are flash-based players with 256 MB respectively 512 MB storage capacity. They have the usual FM radio which can be recorded in addition to voice. They also have a 1,9" color display.<br />
<br />
* [http://www.lexar.com/mp3/index.html Lexar's] LDP-800<br />
:Available from 03/2005 the LDP-800 is offering MP3, WMA and Ogg Vorbis Support with 256/512MB storage. It has a digital out, FM receiver and transmitter, can record from FM, mic and line-in and has a SD-card slot. Includes Sennheiser earbuds. Update: A telephoned sales representative informed on 2005-04-15 that this player would be available sometime in June. Update again: A sales representative telephoned on 2005-06-20 again stated that the player would be available sometime in June. However, a sales representitave at [http://www.ecost.com/ eCOST], an online store carrying the LDP-800, stated that their availability date is now 2005-07-15. Lexar now seem to have dropped this product. See discussion.<br />
<br />
* [http://www.maxfield.de/ Maxfield's] Max-Diamond, Max-Movie, Max-Diablo<br />
: It's not yet on the homepage, but the Max-Diamond will be released in 03/2005 and supports MP3, Ogg Vorbis and WMA (DRM). It has 512MB flash memory and can record from FM radio. The Max-Movie has 1GB storage and supports DivX, MP3 WMA (DRM) and Ogg Vorbis. It also has FM radio and a display with 260.000 colors. The Max-Diablo supports the same audio formats, but can also display pictures and videos on its small OLED (4096 colors). It has 1GB storage.<br />
<br />
* [http://www.mbird.co.kr/ M-bird's] XT-22S<br />
: Available in 256MB/512MB/1GB sizes. USB 2.0. Supports Ogg Vorbis (although it doesn't seem to view tag info, will probably be fixed in future firmwares (?)), but also MP3 and WMA. It has small 200 mW built-in speaker. Inverted display with the ability to choose the foreground colour in 125 steps. Other features include FM-radio, voice recorder (built-in mic), line-in, alarm, and more.<br />
<br />
* [http://mpeye.net/ MPeye] TS-400<br />
:a flash player which comes in 128MB/256MB/512MB/1GB sizes, has a FM-receiver, colour display and a voice recorder. <br />
<br />
* [http://www.muzio.co.kr/ Muzio's] JM200, JM250, JM300<br />
:Another Korean manufacturer jumps in and offers small flash-based players with 128MB up to 1GB storage capacities. They support the usual formats MP3/WMA/Ogg Vorbis, can record voice, receive FM radio.<br />
<br />
* [http://www.neurosaudio.com/ Neuros'] Neuros II<br />
:The Neuros II can be used as a stand-alone flash-player. You can later buy an HDD "backpack" from 20 to 80 gigs in size and switch the backpacks as you please. This player now has a [http://open.neurosaudio.com/ free software (open-source) firmware].<br />
<br />
* [http://www.pretec.com/OnlineSales/SSD/iDisk/Allegro/Allegro.htm Pretec's] Allegro<br />
:The player supports MP3, WMA and Ogg Vorbis formats, uses USB Flash Drives for storage, has a 128x64 pixel blue screen with file info in 5 languages, 6 preset sound stages, one user defined graphic equalizer, low power consumption.<br />
<br />
* [http://eng.qoolqee.com/ Qoolqee's] K7<br />
:This is an interesting mix of a flash-based MP3 player and an organizer: the player has 512/1024 MB storage and contact and calendar functions and can sync with Outlook. It supports MP3, WMA and Ogg Vorbis, has FM radio and connectors for two headphones.<br />
<br />
* [http://www.samsung.com/Products/ Samsung] / [http://www.yepp.co.kr/ Yepp] (product label), YP-T6, YP-T7, YP-C1, YP-F1, YP-MT6, YP-53, YP-U1<br />
:The YP-T6 is an incredibly small flash player with 128/256/512/1024 MB storage, has a mic and FM radio and supports MP3, WMA (DRM) and Ogg Vorbis. The YP-T7 has either 512MB or 1GB capacity and supports the same audio formats, which also applies to the YP-F1. It can display JPEGs on its color display. The YP-C1 has similar specs, including Ogg support; at the time of writing, it seems to be readily available only in Korea and China. The YP-53, a small flash player with 128/256/512/1024 MB storage, mic, USB 2.0 and FM radio, supports MP3, WAV, WMA(DRM), Ogg Vorbis(-q >= 0) with Firmware 1.200. The YP-U1 is a small (2,38 x 8,78 x 1,35 cm, ~32g) flash player with 128/256/512/1024/2048 MB storage. The player has a LCD b/w display and an integrated accumulator that is charged via USB. It supports USB2.0 and has an integrated USB-plug that can be flipped in and out, so no cable or adapter is needed. Besides OGG the YP-U1 supports MP3, ASF and WMA (and directory structures). <br />
<br />
:*[[Talk:PortablePlayers#Samsung's Yepp Ogg Vorbis support|There have been reports that the Ogg Vorbis support in the YP-T6 is buggy.]]<br />
<br />
* [http://www.teac.com/ TEAC's] MP-400<br />
:The MP-400 is a flsh-player with either 512/1024MB storage. It supports MP3, WMA, Ogg Vorbis and MPEG-4 video.<br />
<br />
* [http://www.trekstor.de/ TrekStor's] iBeat fresh, iBeat organix, iBeat cube, iBeat ice, iBeat vision<br />
:The iBeat fresh comes with 256/512 MB storage has a 64K color display and the usual features. The iBeat organix is supposed to get a firmware upgrade and comes with 256/512/1024 MB flash memory. The iBeat cube is a very small player with the usual features. The iBeat ice has a sharp OLED display. The iBeat vision has a large display that can be used to watch movies. It comes in sizes from 256MB to 2GB.<br />
<br />
* [http://www.wigobyte.com/ Wigo's] CVM-101, CVM-103, CVM-300, CVS-100<br />
:Korean players with slick design, comes in 128/256/512/1024 MB depending on models. Support MP3/WMA/Ogg, FM receiver, voice recorder. Note: Ogg bitrates supported may be limited, check the manufacturer's specification for each device for details.<br />
<br />
* [http://www.xcent.co.kr Xcent's] XT100<br />
:This player is sold in the U.K. and comes with 256/512MB. It supports MP3, WMA, Ogg Vorbis and has FM radio and voice recording. It also works under Linux (kernel 2.4 upwards) and FreeBSD 5.3 (recognised as a removable mass storage device).<br />
<br />
== Harddisk Storage ==<br />
<br />
* [http://www.airlinktek.com/ AL Tech's] MG-25, MG-35, MG350HD<br />
:The Mediagate MG-25 is a portable HDD that supports also media playback. It uses a 2,5" disk and USB2.0 to connect, and supports MPEG-1/-2/-4, DivX, Xvid, MP3, Ogg Vorbis, JPG. It can upsample to HDTV, has composite, component and s-video outs, stereo and a digital out. Remote control is included. The MG-35 uses a 3,5" HDD instead, supports WMA and ethernet. The MG350HD uses a 3,5" HDD as well and supports HDTV.<br />
<br />
* [http://www.boghe.com/products/audio/vip20.htm Boghe] Vip20<br />
:The Vip20 seems to be similar to the iBeat 500 from TrekStor and Xclef HD-800. It has the same features: MP3, WMA, WAV, Ogg Vorbis decoding plus 20 GB storage.<br />
<br />
* [http://www.commodore.net/ Commodore's] eVic<br />
:The eVic has 20GB storage and plays WMA (incl. DRM), MP3 and Ogg Vorbis. It can record voice and music, and has USB host functionality.<br />
<br />
* [http://www.digmind.com/ Digital Mind Corporation's] DMC 8280<br />
:The [http://www.digmind.com/store/index_8280.html DMC 8280] has 20 GB or 30 GB storage, plays Ogg Vorbis, MP3 and WMA. Standard feature set; this player does not excel in any area but price. USB mass storage compliant -- you can put songs on it from non-Windows computers, but full indexing of the songs for reference by artist etc. requires Windows.<br />
<br />
* [http://www.freecom.com/ Freecom's] MediaPlayer-3, Network MediaPlayer-35 Drive-In<br />
:The MediaPlayer-3 is again sort of an external HDD that can play media without a PC. It supports DivX, MP3, MPEG-4, AVI, WMA, ASF and Ogg Vorbis. The product with the complicated name Network MediaPlayer-35 Drive-In is an enhanced version of the MediaPlayer-3 -- it has an additional network interface and supports an internal 3,5" drive. The ethernet port can be used to read media from the network, but cannot be used as network attached storage.<br />
<br />
* [http://www.godot.com.tw/ GoDot] M8170, M8270, M8370, M8470, M8570<br />
:GoDot's HD players have capacity ranging from 2.2gb to 20gb. Each model is very different. They support Ogg Vorbis, MP3 and WMA (some models support DRM).<br />
<br />
* [http://www.hama.de/portal?lid=2 Hama's] VSV-20<br />
:The VSV-20 has the usual mobile MP3 HDD player size and can read/write from its 16in1 memory card reader and 20 GB internal HDD. But it can do more than audio (MP3, WMA, Ogg Vorbis, AAC). It supports image (JPEG) and video (MPEG-1/-4) playback on the 2" display and on a connected TV. It even includes a remote control.<br />
<br />
* [http://eng.iaudio.com/ iAudio] M3, X5<br />
:The iAudio M3 is a portable harddisk player with either 20 or 40 GB of storage. It has a built-in FM radio and mic. It supports MP3, WMA, Ogg Vorbis and WAV and even FLAC with the newest firmware upgrade. See this [http://gear.ign.com/articles/522/522090p1.html IGN article] for more info. <br />
:The [http://www.engadget.com/entry/0377386638551474 iAudio M5] is announced for end 2004. It comes with colour display and USB-on-the-go function for 20GB storage.<br />
:It appears that the M5 is indeed called X5 and already available through [http://www.mp3-player.de/artikel.php?ArtNr=1375&id=128 Shops] in 20GB, 30GB and 60GB. It hasn't been listed on iAudio's English pages, but was mentioned in a [http://eng.cowon.com/hboard/view.php?boardID=E03&number=48 press release] earlier this year:<br />
::"<i>Other major new releases on display include the iAUDIO X5, a next-generation HDD-type MP3 player featuring a 1.8 inch, 260,000 color LCD, and iAUDIO M5L, a super-light, ultra-compact HDD-type MP3 player. iAUDIO X5, a state-of-the-art HDD-type MP3 player can not only play music, but various images and videos as well without a PC by directly connecting to a digital camera using its OTG (On-The-Go) feature. iAUDIO M5L is a HDD-type MP3 player that features 36 hours of continuous playback time, probably the longest of its kind in the world.</i>"<br />
:The X5 now available in the US at [http://onlinestore.cowonamerica.com/index.asp?PageAction=VIEWCATS&Category=60 Cowon's Online Store]<br />
<br />
* [http://www.ivmm.com/innoax/products_innopod.html InnoAX's] InnoPod<br />
:This is a iPod mini clone, that supports MP3, WMA, WAV and Ogg Vorbis. It supports recording from line-in and mic, has a 4 GB harddrive and USB2.0.<br />
<br />
* [http://www.iriver.com/ iRiver's] iHP-1xx, H1xx, H2xx, H3xx, iGP-100<br />
:iRiver has also a number of harddisk based items that play back Ogg Vorbis. Older models like the [http://www.iriver.com/product/info.asp?p_name=iHP-100 iHP-100] and the [http://www.iriver.co.kr/product/info.asp?p_group=iHP&amp;p_name=iHP-115 iHP-115] come in 10 and 15 GB sizes and need a firmware update (see the [http://www.iriver.com/support/download.asp support downloads] for that). The [http://www.iriver.com/product/info.asp?p_name=iHP-120 iHP-120], a 20GB portable player, and the [http://www.iriver.com/product/info.asp?p_name=iHP-140 iHP-140], a 40GB version, support Vorbis playback out of the box. Read reviews here: [http://gear.ign.com/articles/435/435472p1.html IGN on iHP-100], [http://gear.ign.com/articles/457/457818p1.html IGN on iHP-120]. The [http://www.iriveramerica.com/products/iGP-100.asp iGP-100], a 1.5Gb portable player, supports Vorbis, according to the FAQ, though no firmware upgrade appears to be required. The new line of harddisk players [http://www.iriver.com/product/info.asp?p_name=H140H110 H120, H140] come in 10 to 40 GB sizes. There is also a product line with USB host function and colour display that supports 32-500kbs: [http://www.iriver.com/product/info.asp?p_name=H340 H320, H340].<br />
<br />
* [http://www.jetaudio.com/products/tvix/ JetAudio's] [http://www.tvix.co.kr/eng/ Dvico's] TViX<br />
:This is a rather unique device. JetAudio calls it a multimedia jukebox, music tank, photo album and last but not least a portable storage. It is bigger than usual portable devices, but has also a lot more options. It can connect to the PC (USB 2.0), TV (S-Video, Composite), stereos and 5.1 surround systems (Coaxial/Optical) and comes with a remote control. Supported video formats are DVD (MPEG-2), VCD (MPEG-1), DivX, Xvid. Supported Audio formats are MP3, WMA and Ogg Vorbis. It can display JPEG pictures on the TV. It is available without a harddrive, or equipped with harddrive sizes up to 200 GB.<br />
<br />
* [http://www.jnc-digital.com/Eng/ JNC's] SSF-M3, SSF-M5<br />
:The SSF-M3 comes with 20/40GB storage size, whereas the SSF-M5 has only 1.5 GB. Both support voice recording and FM radio. The SSF-M3 is more stylish and very slim and comes with a docking station.<br />
<br />
* [http://www.lge.com/ LG's] Mediagate<br />
:This player is similar to the Modix or TViX. It is a portable USB HDD equipped with a 2,5" drive (size varies). It plays audio (MP3, Ogg Vorbis, WMA), video (MPEG-1/-2, Xvid, DivX) and images (JPEG). It has composite, s-video and component video output and supports progressive scan, audio output is done through a coaxial and stereo plug. The device is bundled with a remote control.<br />
<br />
* [http://www.modix.co.kr/ Modix] HD-3510<br />
:The HD-3510 is similar to the TViX, as it is sort of a portable multi-talent. It can store and playback audio, video and images, and can be used for other files as well. It can decode MPEG-1/-2/-4 including DivX/Xvid, AC3, DTS, MP3, WMA, Ogg Vorbis and JPEG. It uses USB2.0 for data input and has various ouput connectors: anlog stereo and 5.1 out, coaxial digital out, composite, s-video and component video out with progressive scan and HDTV upscaling. The HD-3510 is bundled with a carrying bag and a remote control, but without a 3,5" HDD.<br />
<br />
* [http://mpeye.net/ MPeye's] HT-100, HT-150<br />
:The HT-100 uses a 1,5 GB HDD, decodes MP3, WMA, Ogg Vorbis and supports the usual features. The HT-150 seems to have the same features (maybe a mistake on the website).<br />
<br />
* [http://www.mpio.com/ mpio] HD300, HD200, One<br />
:mpio HD300 is a harddisk player with 20GB and supports WAV/MP3/WMA/Ogg Vorbis. It has FM radio, an alarm clock and supports USB 2.0. The HD200 has 5GB storage capacity, a FM radio which can be recorded and supports the same formats as the HD300. Despite its name the One consist of three components: a player, a HDD and a CD-ROM drive, which can be combined with each other. It supports [[MP3]], [[WMA]], Ogg Vorbis, JPG, BMP and MPEG-4 movies. It has a 1" OLED display and will be available from 05/2005.<br />
<br />
* [http://www.imp3.net/read.php?textid=1529 Muzio's] JM-600<br />
:This player comes with either 2.2 or 4 GB harddrive and supports MP3, WMA, Ogg Vorbis and ASF. It can record voice and has a FM receiver. What sets this player apart is the LCD -- it can show BMPs, JPGs and text. The device can also act as a USB host to support digital cameras.<br />
<br />
* [http://www.macpower.com.tw/ Macpower] Mvisto MV-U2UGS<br />
:The Mvisto is a portable hardware enclosure for 2,5" harddrives. It has video and audio outs and decodes MPEG1/2/Divx/Xvid/JPEG/MP3/WMA/AAC/Ogg Vorbis. It comes with a remote control.<br />
<br />
* [http://www.neurosaudio.com/ Neuros'] Neuros II<br />
:This mobile player comes either with various harddrive sizes up to 80 GB or as 256 MB flash player. The new firmware to support Ogg Vorbis has been developed by the Xiph.org Foundation (see the [http://www.neurosaudio.com/press/news_item.aspx?itemID=80 press release]). Get the newest firmware version at Neuros' [http://www.neurosaudio.com/support/support_updates.asp support page]). The Neuros Synchronization Manager for Windows is available from the same link and now fully supports the addition of Vorbis files to the Neuros. *nix users can use Xiph.org's [http://www.xiph.org/positron/ Positron], Sean Starkey's Java [http://neurosdbm.sf.net/ Neuros Database Manipulator], or [http://www.sorune.com/ Sorune], all of which provide full Neuros database support and other features. Neuros II discontinued. Neuros III is planned but indefinite but they have a [http://open.neurosaudio.com/archives/Product%20Roadmap3-15-2005.htm roadmap].<br />
<br />
* [http://www.nextway.co.kr/ Nextway's] D Cube NHD-150D<br />
:This player uses a small 1,5 GB harddisk and supports MP3, WMA and Ogg Vorbis. It connects trough USB 2.0 and can broadcast music through a FM sender.<br />
<br />
* [http://www.pontis.de/ Pontis'] MX2020<br />
:There is now a firmware update for the MX2020 that adds Ogg Vorbis support, which is a portable player for movies, music and photos.<br />
<br />
* [http://www.modix-hd.com/ Rapsody's] RSH-100<br />
:It is similar to the Modix HD-3510, but supports USB host functionality additionally. This web site is dead. The Savit Micro Rapsody [http://www.savitmicro.co.kr/eng/product/tv/tv_rapsody.htm RSH-100] can be seen on their site.<br />
<br />
* [http://www.digitalnetworksna.com/rioaudio/ Rio's] Karma<br />
:The Rio [http://www.digitalnetworksna.com/shop/item.asp?model=261 Karma] is a portable player with a harddisk of 20 GB. It can decode MP3, Ogg Vorbis and FLAC. USB 2.0 is used to connect to PCs, but a docking station is also included which offers ethernet and RCA line-out support. IGN has written a [http://gear.ign.com/articles/458/458401p1.html review] about the gadget, articles about the Karma can be found at [http://www.riovolution.com Riovolution]. Note that firmware versions prior to 1.25 cause stability problems for some people, visit the [http://www.digitalnetworksna.com/support/rio/product.asp?prodID=113 support page] to get the newest version. The Karma was discontinued in March 2005, Rio (DNNA) effectively dissolved 27-July-2005 assets sold to [http://www.sigmatel.com/ SigmaTel].<br />
<br />
* [http://www.safa.com.hk/index_110R.html Safa] HMP-110R<br />
:A portable player with 1.5GB memory, FM-receiver, recording function, upgradeable firmware, etc.<br />
<br />
* [http://www.samsung.com Samsung] YH-J70<br />
:A portable Multimedia Jukebox as seen on their [http://www.samsung.com/common/microsite/exhibition/cebit2005/base.asp?pcode=IT01 Cebit 2005 Microsite]. Comes with 20/30GB disk, colour display, video player and USB host function<br />
<br />
* [http://www.sitecom.com/ Sitecom's] MP-330, MP-010<br />
:The MP-330 player uses a 4,4 GB harddrive, USB 2.0 and supports MP3, WMA and Ogg Vorbis (mentioned in the manual). The MP-010 is a portable media player. As such it supports music, movies and pictures. This includes MP3, WMA, Ogg Vorbis, MPEG-1/-2/-4. It has a capacity of 40GB, comes with a remote control and has various ports for the TV.<br />
<br />
* [http://www.teac.de/ TEAC] MP-1000, MP-2000<br />
:TEAC MP-1000 is an ultra-compact harddrive player with 1.5GB capacity and only 70g mass. The follow-up model MP-2000 has 5 GB storage and supports the same formats (MP3, WMA, Ogg Vorbis).<br />
<br />
* [http://www.trekstor.de/ TrekStor's] iBeat 500, iBeat 300<br />
:The iBeat 500 is a portable harddisk player with 20 GB of storage. It supports MP3, WMA and Ogg Vorbis and uses USB 2.0 to connect to PCs. It has a FM radio and an in-built mic. It seems to be available only in Germany (looks like a rebadged Xclef HD-800). The iBeat 300 uses a 1,5 GB HDD and has a color display.<br />
<br />
* [http://www.unibrain.com/iZak Unibrain's] iZak<br />
:This is a portable USB hard disk with 40/80/100 GB of storage. It plays a wide range of video formats, including dixv/xvid/bvix/dvd iso. A good review can be found [http://www.mpeg-playcenter.com/modules/Reviews/reviews/Review_iZak.pdf here].<br />
:The most current firmware release supports Ogg Vorbis playback according to [http://www.unibrain.com/support/iZak/iZak_FAQ.htm Unibrain's iZak FAQ].<br />
<br />
* [http://www.xclef.com/ Xclef's] HD-800, HD-500<br />
:This is a harddisk player with 20/40/60 GB storage size, and can decode MP3, WMA, Ogg Vorbis and WAV. It has a FM radio and a mic for recording voice. Though not mentioned on the web site, the HD-500 is also supposed to decode Ogg Vorbis.<br />
<br />
== CD/DVD Audio Players ==<br />
<br />
* [http://www.ifreemax.com/ Freemax's] FW-960<br />
:This CD-R portable supports Ogg Vorbis playback out of the box. It has 48 hours of WMA playback if an external battery pack (2 AA batteries) is used. The FreeMax FW-960 is also known as the mpman MP-CD550.<br />
<br />
* [http://www.exonion.com/ Havin's] (link dead) Exonion HVC-400E, [http://www.princeton.co.jp/ Princeton's] Pocket Beat airCD<br />
:The Havin HVC-400E, also known as the Princeton airCD is probably on sale in Japan since late November, 2003.<br />
<br />
* [http://www.iriver.com/product/info.asp?p_name=iMP-550 iRiver] iMP-250, iMP-350, iMP-400, iMP-550, iMP-700(T)<br />
:Ogg Vorbis is supported only through latest beta firmwares, still some bitrate restriction which may vary depending on the model (min=96kbps, max=160kbps). The iMP-550 supports maximum bitrate up to 256kps (still 96kbps as minimum). Also note the latest iMP-450 does not support OGG for the moment, a future upgrade may correct this... The iMP-700T with firmware 1.40 supports bitrates between 96 and 210 kbps, and .ogg files are generally not as loud as .mp3 files.<br />
<br />
* [http://www.samsungusa.com/ Samsung's] MCD-CM600<br />
:The MCD-CM600 is now available in Korea. It is a CD portable that can play Vorbis, MP3, and WMA.<br />
<br />
* [http://www.roadstar.com/ Roadstar] PCD-5960WOMPT<br />
<br />
== Portable Digital Assisstants (PDAs) ==<br />
<br />
PDAs are also cable of operating as portable music players using available software applications. Please visit [http://wiki.xiph.org/index.php/VorbisSoftwarePlayers VorbisSoftwarePlayers] for more information.<br />
<br />
------------</div>Gumboot