[758c94]: doc / Vorbis_I_spec.html  Maximize  Restore  History

Download this file

2293 lines (2074 with data), 170.9 kB

   1
   2
   3
   4
   5
   6
   7
   8
   9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58
  59
  60
  61
  62
  63
  64
  65
  66
  67
  68
  69
  70
  71
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114
 115
 116
 117
 118
 119
 120
 121
 122
 123
 124
 125
 126
 127
 128
 129
 130
 131
 132
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170
 171
 172
 173
 174
 175
 176
 177
 178
 179
 180
 181
 182
 183
 184
 185
 186
 187
 188
 189
 190
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226
 227
 228
 229
 230
 231
 232
 233
 234
 235
 236
 237
 238
 239
 240
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282
 283
 284
 285
 286
 287
 288
 289
 290
 291
 292
 293
 294
 295
 296
 297
 298
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338
 339
 340
 341
 342
 343
 344
 345
 346
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394
 395
 396
 397
 398
 399
 400
 401
 402
 403
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450
 451
 452
 453
 454
 455
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506
 507
 508
 509
 510
 511
 512
 513
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562
 563
 564
 565
 566
 567
 568
 569
 570
 571
 572
 573
 574
 575
 576
 577
 578
 579
 580
 581
 582
 583
 584
 585
 586
 587
 588
 589
 590
 591
 592
 593
 594
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618
 619
 620
 621
 622
 623
 624
 625
 626
 627
 628
 629
 630
 631
 632
 633
 634
 635
 636
 637
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674
 675
 676
 677
 678
 679
 680
 681
 682
 683
 684
 685
 686
 687
 688
 689
 690
 691
 692
 693
 694
 695
 696
 697
 698
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730
 731
 732
 733
 734
 735
 736
 737
 738
 739
 740
 741
 742
 743
 744
 745
 746
 747
 748
 749
 750
 751
 752
 753
 754
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786
 787
 788
 789
 790
 791
 792
 793
 794
 795
 796
 797
 798
 799
 800
 801
 802
 803
 804
 805
 806
 807
 808
 809
 810
 811
 812
 813
 814
 815
 816
 817
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842
 843
 844
 845
 846
 847
 848
 849
 850
 851
 852
 853
 854
 855
 856
 857
 858
 859
 860
 861
 862
 863
 864
 865
 866
 867
 868
 869
 870
 871
 872
 873
 874
 875
 876
 877
 878
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898
 899
 900
 901
 902
 903
 904
 905
 906
 907
 908
 909
 910
 911
 912
 913
 914
 915
 916
 917
 918
 919
 920
 921
 922
 923
 924
 925
 926
 927
 928
 929
 930
 931
 932
 933
 934
 935
 936
 937
 938
 939
 940
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951
 952
 953
 954
 955
 956
 957
 958
 959
 960
 961
 962
 963
 964
 965
 966
 967
 968
 969
 970
 971
 972
 973
 974
 975
 976
 977
 978
 979
 980
 981
 982
 983
 984
 985
 986
 987
 988
 989
 990
 991
 992
 993
 994
 995
 996
 997
 998
 999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Vorbis I specification</title><meta name="generator" content="DocBook XSL Stylesheets V1.71.0"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="article" lang="en"><div class="titlepage"><div><div><h1 class="title"><a name="id291327"></a>Vorbis I specification</h1></div><div><h3 class="corpauthor">Xiph.org Foundation</h3></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#vorbis-spec-intro">1. Introduction and Description</a></span></dt><dd><dl><dt><span class="section"><a href="#id311592">1.1. Overview</a></span></dt><dt><span class="section"><a href="#id258770">1.2. Decoder Configuration</a></span></dt><dt><span class="section"><a href="#id258461">1.3. High-level Decode Process</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-bitpacking">2. Bitpacking Convention</a></span></dt><dd><dl><dt><span class="section"><a href="#id304831">2.1. Overview</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-codebook">3. Probability Model and Codebooks</a></span></dt><dd><dl><dt><span class="section"><a href="#id310158">3.1. Overview</a></span></dt><dt><span class="section"><a href="#id310216">3.2. Packed codebook format</a></span></dt><dt><span class="section"><a href="#id316518">3.3. Use of the codebook abstraction</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-codec">4. Codec Setup and Packet Decode</a></span></dt><dd><dl><dt><span class="section"><a href="#id336024">4.1. Overview</a></span></dt><dt><span class="section"><a href="#id326710">4.2. Header decode and decode setup</a></span></dt><dt><span class="section"><a href="#id342709">4.3. Audio packet decode and synthesis</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-comment">5. comment field and header specification</a></span></dt><dd><dl><dt><span class="section"><a href="#id314030">5.1. Overview</a></span></dt><dt><span class="section"><a href="#id314058">5.2. Comment encoding</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-floor0">6. Floor type 0 setup and decode</a></span></dt><dd><dl><dt><span class="section"><a href="#id336814">6.1. Overview</a></span></dt><dt><span class="section"><a href="#id321046">6.2. Floor 0 format</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-floor1">7. Floor type 1 setup and decode</a></span></dt><dd><dl><dt><span class="section"><a href="#id336243">7.1. Overview</a></span></dt><dt><span class="section"><a href="#id334800">7.2. Floor 1 format</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-residue">8. Residue setup and decode</a></span></dt><dd><dl><dt><span class="section"><a href="#id320982">8.1. Overview</a></span></dt><dt><span class="section"><a href="#id307154">8.2. Residue format</a></span></dt><dt><span class="section"><a href="#id326310">8.3. residue 0</a></span></dt><dt><span class="section"><a href="#id326344">8.4. residue 1</a></span></dt><dt><span class="section"><a href="#id334893">8.5. residue 2</a></span></dt><dt><span class="section"><a href="#id334939">8.6. Residue decode</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-helper">9. Helper equations</a></span></dt><dd><dl><dt><span class="section"><a href="#id316603">9.1. Overview</a></span></dt><dt><span class="section"><a href="#id317505">9.2. Functions</a></span></dt></dl></dd><dt><span class="section"><a href="#vorbis-spec-tables">10. Tables</a></span></dt><dd><dl><dt><span class="section"><a href="#vorbis-spec-floor1_inverse_dB_table">10.1. floor1_inverse_dB_table</a></span></dt></dl></dd><dt><span class="appendix"><a href="#vorbis-over-ogg">1. Embedding Vorbis into an Ogg stream</a></span></dt><dd><dl><dt><span class="section"><a href="#id319760">1.1. Overview</a></span></dt><dd><dl><dt><span class="section"><a href="#id336562">1.1.1. Restrictions</a></span></dt><dt><span class="section"><a href="#id330723">1.1.2. MIME type</a></span></dt></dl></dd><dt><span class="section"><a href="#id328095">1.2. Encapsulation</a></span></dt></dl></dd><dt><span class="appendix"><a href="#vorbis-over-rtp">2. Vorbis encapsulation in RTP</a></span></dt><dt><span class="appendix"><a href="#footer">3. Colophon</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="vorbis-spec-intro"></a>1.�Introduction and Description</h2></div><div><p class="releaseinfo">
$Id: 01-introduction.xml 7186 2004-07-20 07:19:25Z xiphmont $
</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id311592"></a>1.1.�Overview</h3></div></div></div><p>
This document provides a high level description of the Vorbis codec's
construction. A bit-by-bit specification appears beginning in
<a href="#vorbis-spec-codec" title="4.�Codec Setup and Packet Decode">Section�4, &#8220;Codec Setup and Packet Decode&#8221;</a>.
The later sections assume a high-level
understanding of the Vorbis decode process, which is
provided here.</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id317198"></a>1.1.1.�Application</h4></div></div></div><p>
Vorbis is a general purpose perceptual audio CODEC intended to allow
maximum encoder flexibility, thus allowing it to scale competitively
over an exceptionally wide range of bitrates. At the high
quality/bitrate end of the scale (CD or DAT rate stereo, 16/24 bits)
it is in the same league as MPEG-2 and MPC. Similarly, the 1.0
encoder can encode high-quality CD and DAT rate stereo at below 48kbps
without resampling to a lower rate. Vorbis is also intended for
lower and higher sample rates (from 8kHz telephony to 192kHz digital
masters) and a range of channel representations (monaural,
polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 255
discrete channels).
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id315630"></a>1.1.2.�Classification</h4></div></div></div><p>
Vorbis I is a forward-adaptive monolithic transform CODEC based on the
Modified Discrete Cosine Transform. The codec is structured to allow
addition of a hybrid wavelet filterbank in Vorbis II to offer better
transient response and reproduction using a transform better suited to
localized time events.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id323943"></a>1.1.3.�Assumptions</h4></div></div></div><p>
The Vorbis CODEC design assumes a complex, psychoacoustically-aware
encoder and simple, low-complexity decoder. Vorbis decode is
computationally simpler than mp3, although it does require more
working memory as Vorbis has no static probability model; the vector
codebooks used in the first stage of decoding from the bitstream are
packed in their entirety into the Vorbis bitstream headers. In
packed form, these codebooks occupy only a few kilobytes; the extent
to which they are pre-decoded into a cache is the dominant factor in
decoder memory usage.
</p><p>
Vorbis provides none of its own framing, synchronization or protection
against errors; it is solely a method of accepting input audio,
dividing it into individual frames and compressing these frames into
raw, unformatted 'packets'. The decoder then accepts these raw
packets in sequence, decodes them, synthesizes audio frames from
them, and reassembles the frames into a facsimile of the original
audio stream. Vorbis is a free-form variable bit rate (VBR) codec and packets have no
minimum size, maximum size, or fixed/expected size. Packets
are designed that they may be truncated (or padded) and remain
decodable; this is not to be considered an error condition and is used
extensively in bitrate management in peeling. Both the transport
mechanism and decoder must allow that a packet may be any size, or
end before or after packet decode expects.</p><p>
Vorbis packets are thus intended to be used with a transport mechanism
that provides free-form framing, sync, positioning and error correction
in accordance with these design assumptions, such as Ogg (for file
transport) or RTP (for network multicast). For purposes of a few
examples in this document, we will assume that Vorbis is to be
embedded in an Ogg stream specifically, although this is by no means a
requirement or fundamental assumption in the Vorbis design.</p><p>
The specification for embedding Vorbis into
an Ogg transport stream is in <a href="#vorbis-over-ogg" title="1.�Embedding Vorbis into an Ogg stream">Appendix�1, <i>Embedding Vorbis into an Ogg stream</i></a>.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id324282"></a>1.1.4.�Codec Setup and Probability Model</h4></div></div></div><p>
Vorbis' heritage is as a research CODEC and its current design
reflects a desire to allow multiple decades of continuous encoder
improvement before running out of room within the codec specification.
For these reasons, configurable aspects of codec setup intentionally
lean toward the extreme of forward adaptive.</p><p>
The single most controversial design decision in Vorbis (and the most
unusual for a Vorbis developer to keep in mind) is that the entire
probability model of the codec, the Huffman and VQ codebooks, is
packed into the bitstream header along with extensive CODEC setup
parameters (often several hundred fields). This makes it impossible,
as it would be with MPEG audio layers, to embed a simple frame type
flag in each audio packet, or begin decode at any frame in the stream
without having previously fetched the codec setup header.
</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
Vorbis <span class="emphasis"><em>can</em></span> initiate decode at any arbitrary packet within a
bitstream so long as the codec has been initialized/setup with the
setup headers.</p></div><p>
Thus, Vorbis headers are both required for decode to begin and
relatively large as bitstream headers go. The header size is
unbounded, although for streaming a rule-of-thumb of 4kB or less is
recommended (and Xiph.Org's Vorbis encoder follows this suggestion).</p><p>
Our own design work indicates the primary liability of the
required header is in mindshare; it is an unusual design and thus
causes some amount of complaint among engineers as this runs against
current design trends (and also points out limitations in some
existing software/interface designs, such as Windows' ACM codec
framework). However, we find that it does not fundamentally limit
Vorbis' suitable application space.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258744"></a>1.1.5.�Format Specification</h4></div></div></div><p>
The Vorbis format is well-defined by its decode specification; any
encoder that produces packets that are correctly decoded by the
reference Vorbis decoder described below may be considered a proper
Vorbis encoder. A decoder must faithfully and completely implement
the specification defined below (except where noted) to be considered
a proper Vorbis decoder.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258756"></a>1.1.6.�Hardware Profile</h4></div></div></div><p>
Although Vorbis decode is computationally simple, it may still run
into specific limitations of an embedded design. For this reason,
embedded designs are allowed to deviate in limited ways from the
'full' decode specification yet still be certified compliant. These
optional omissions are labelled in the spec where relevant.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id258770"></a>1.2.�Decoder Configuration</h3></div></div></div><p>
Decoder setup consists of configuration of multiple, self-contained
component abstractions that perform specific functions in the decode
pipeline. Each different component instance of a specific type is
semantically interchangeable; decoder configuration consists both of
internal component configuration, as well as arrangement of specific
instances into a decode pipeline. Componentry arrangement is roughly
as follows:</p><div class="mediaobject"><img src="components.png" alt="decoder pipeline configuration"></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258803"></a>1.2.1.�Global Config</h4></div></div></div><p>
Global codec configuration consists of a few audio related fields
(sample rate, channels), Vorbis version (always '0' in Vorbis I),
bitrate hints, and the lists of component instances. All other
configuration is in the context of specific components.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258815"></a>1.2.2.�Mode</h4></div></div></div><p>
Each Vorbis frame is coded according to a master 'mode'. A bitstream
may use one or many modes.</p><p>
The mode mechanism is used to encode a frame according to one of
multiple possible methods with the intention of choosing a method best
suited to that frame. Different modes are, e.g. how frame size
is changed from frame to frame. The mode number of a frame serves as a
top level configuration switch for all other specific aspects of frame
decode.</p><p>
A 'mode' configuration consists of a frame size setting, window type
(always 0, the Vorbis window, in Vorbis I), transform type (always
type 0, the MDCT, in Vorbis I) and a mapping number. The mapping
number specifies which mapping configuration instance to use for
low-level packet decode and synthesis.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258359"></a>1.2.3.�Mapping</h4></div></div></div><p>
A mapping contains a channel coupling description and a list of
'submaps' that bundle sets of channel vectors together for grouped
encoding and decoding. These submaps are not references to external
components; the submap list is internal and specific to a mapping.</p><p>
A 'submap' is a configuration/grouping that applies to a subset of
floor and residue vectors within a mapping. The submap functions as a
last layer of indirection such that specific special floor or residue
settings can be applied not only to all the vectors in a given mode,
but also specific vectors in a specific mode. Each submap specifies
the proper floor and residue instance number to use for decoding that
submap's spectral floor and spectral residue vectors.</p><p>
As an example:</p><p>
Assume a Vorbis stream that contains six channels in the standard 5.1
format. The sixth channel, as is normal in 5.1, is bass only.
Therefore it would be wasteful to encode a full-spectrum version of it
as with the other channels. The submapping mechanism can be used to
apply a full range floor and residue encoding to channels 0 through 4,
and a bass-only representation to the bass channel, thus saving space.
In this example, channels 0-4 belong to submap 0 (which indicates use
of a full-range floor) and channel 5 belongs to submap 1, which uses a
bass-only representation.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258391"></a>1.2.4.�Floor</h4></div></div></div><p>
Vorbis encodes a spectral 'floor' vector for each PCM channel. This
vector is a low-resolution representation of the audio spectrum for
the given channel in the current frame, generally used akin to a
whitening filter. It is named a 'floor' because the Xiph.Org
reference encoder has historically used it as a unit-baseline for
spectral resolution.</p><p>
A floor encoding may be of two types. Floor 0 uses a packed LSP
representation on a dB amplitude scale and Bark frequency scale.
Floor 1 represents the curve as a piecewise linear interpolated
representation on a dB amplitude scale and linear frequency scale.
The two floors are semantically interchangeable in
encoding/decoding. However, floor type 1 provides more stable
inter-frame behavior, and so is the preferred choice in all
coupled-stereo and high bitrate modes. Floor 1 is also considerably
less expensive to decode than floor 0.</p><p>
Floor 0 is not to be considered deprecated, but it is of limited
modern use. No known Vorbis encoder past Xiph.org's own beta 4 makes
use of floor 0.</p><p>
The values coded/decoded by a floor are both compactly formatted and
make use of entropy coding to save space. For this reason, a floor
configuration generally refers to multiple codebooks in the codebook
component list. Entropy coding is thus provided as an abstraction,
and each floor instance may choose from any and all available
codebooks when coding/decoding.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258423"></a>1.2.5.�Residue</h4></div></div></div><p>
The spectral residue is the fine structure of the audio spectrum
once the floor curve has been subtracted out. In simplest terms, it
is coded in the bitstream using cascaded (multi-pass) vector
quantization according to one of three specific packing/coding
algorithms numbered 0 through 2. The packing algorithm details are
configured by residue instance. As with the floor components, the
final VQ/entropy encoding is provided by external codebook instances
and each residue instance may choose from any and all available
codebooks.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258437"></a>1.2.6.�Codebooks</h4></div></div></div><p>
Codebooks are a self-contained abstraction that perform entropy
decoding and, optionally, use the entropy-decoded integer value as an
offset into an index of output value vectors, returning the indicated
vector of values.</p><p>
The entropy coding in a Vorbis I codebook is provided by a standard
Huffman binary tree representation. This tree is tightly packed using
one of several methods, depending on whether codeword lengths are
ordered or unordered, or the tree is sparse.</p><p>
The codebook vector index is similarly packed according to index
characteristic. Most commonly, the vector index is encoded as a
single list of values of possible values that are then permuted into
a list of n-dimensional rows (lattice VQ).</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id258461"></a>1.3.�High-level Decode Process</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258467"></a>1.3.1.�Decode Setup</h4></div></div></div><p>
Before decoding can begin, a decoder must initialize using the
bitstream headers matching the stream to be decoded. Vorbis uses
three header packets; all are required, in-order, by this
specification. Once set up, decode may begin at any audio packet
belonging to the Vorbis stream. In Vorbis I, all packets after the
three initial headers are audio packets. </p><p>
The header packets are, in order, the identification
header, the comments header, and the setup header.</p><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id314074"></a>1.3.1.1.�Identification Header</h5></div></div></div><p>
The identification header identifies the bitstream as Vorbis, Vorbis
version, and the simple audio characteristics of the stream such as
sample rate and number of channels.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id314086"></a>1.3.1.2.�Comment Header</h5></div></div></div><p>
The comment header includes user text comments ("tags") and a vendor
string for the application/library that produced the bitstream. The
encoding and proper use of the comment header is described in
<a href="#vorbis-spec-comment" title="5.�comment field and header specification">Section�5, &#8220;comment field and header specification&#8221;</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id314101"></a>1.3.1.3.�Setup Header</h5></div></div></div><p>
The setup header includes extensive CODEC setup information as well as
the complete VQ and Huffman codebooks needed for decode.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id314113"></a>1.3.2.�Decode Procedure</h4></div></div></div><div class="highlights"><p>
The decoding and synthesis procedure for all audio packets is
fundamentally the same.
</p><div class="orderedlist"><ol type="1"><li>decode packet type flag</li><li>decode mode number</li><li>decode window shape (long windows only)</li><li>decode floor</li><li>decode residue into residue vectors</li><li>inverse channel coupling of residue vectors</li><li>generate floor curve from decoded floor data</li><li>compute dot product of floor and residue, producing audio spectrum vector</li><li>inverse monolithic transform of audio spectrum vector, always an MDCT in Vorbis I</li><li>overlap/add left-hand output of transform with right-hand output of previous frame</li><li>store right hand-data from transform of current frame for future lapping</li><li>if not first frame, return results of overlap/add as audio result of current frame</li></ol></div><p>
</p></div><p>
Note that clever rearrangement of the synthesis arithmetic is
possible; as an example, one can take advantage of symmetries in the
MDCT to store the right-hand transform data of a partial MDCT for a
50% inter-frame buffer space savings, and then complete the transform
later before overlap/add with the next frame. This optimization
produces entirely equivalent output and is naturally perfectly legal.
The decoder must be <span class="emphasis"><em>entirely mathematically equivalent</em></span> to the
specification, it need not be a literal semantic implementation.</p><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id314203"></a>1.3.2.1.�Packet type decode</h5></div></div></div><p>
Vorbis I uses four packet types. The first three packet types mark each
of the three Vorbis headers described above. The fourth packet type
marks an audio packet. All other packet types are reserved; packets
marked with a reserved type should be ignored.</p><p>
Following the three header packets, all packets in a Vorbis I stream
are audio. The first step of audio packet decode is to read and
verify the packet type; <span class="emphasis"><em>a non-audio packet when audio is expected
indicates stream corruption or a non-compliant stream. The decoder
must ignore the packet and not attempt decoding it to
audio</em></span>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id314225"></a>1.3.2.2.�Mode decode</h5></div></div></div><p>
Vorbis allows an encoder to set up multiple, numbered packet 'modes',
as described earlier, all of which may be used in a given Vorbis
stream. The mode is encoded as an integer used as a direct offset into
the mode instance index. </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="vorbis-spec-window"></a>1.3.2.3.�Window shape decode (long windows only)</h5></div></div></div><p>
Vorbis frames may be one of two PCM sample sizes specified during
codec setup. In Vorbis I, legal frame sizes are powers of two from 64
to 8192 samples. Aside from coupling, Vorbis handles channels as
independent vectors and these frame sizes are in samples per channel.</p><p>
Vorbis uses an overlapping transform, namely the MDCT, to blend one
frame into the next, avoiding most inter-frame block boundary
artifacts. The MDCT output of one frame is windowed according to MDCT
requirements, overlapped 50% with the output of the previous frame and
added. The window shape assures seamless reconstruction. </p><p>
This is easy to visualize in the case of equal sized-windows:</p><div class="mediaobject"><img src="window1.png" alt="overlap of two equal-sized windows"></div><p>
And slightly more complex in the case of overlapping unequal sized
windows:</p><div class="mediaobject"><img src="window2.png" alt="overlap of a long and a short window"></div><p>
In the unequal-sized window case, the window shape of the long window
must be modified for seamless lapping as above. It is possible to
correctly infer window shape to be applied to the current window from
knowing the sizes of the current, previous and next window. It is
legal for a decoder to use this method. However, in the case of a long
window (short windows require no modification), Vorbis also codes two
flag bits to specify pre- and post- window shape. Although not
strictly necessary for function, this minor redundancy allows a packet
to be fully decoded to the point of lapping entirely independently of
any other packet, allowing easier abstraction of decode layers as well
as allowing a greater level of easy parallelism in encode and
decode.</p><p>
A description of valid window functions for use with an inverse MDCT
can be found in the paper
&#8220;<span class="citetitle">
<a href="http://www.iocon.com/resource/docs/ps/eusipco_corrected.ps" target="_top">
The use of multirate filter banks for coding of high quality digital
audio</a></span>&#8221;, by T. Sporer, K. Brandenburg and B. Edler. Vorbis windows
all use the slope function
<span class="inlinemediaobject"><span>$y = \sin(.5*\pi \, \sin^2((x+.5)/n*\pi))$</span></span>.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id339168"></a>1.3.2.4.�floor decode</h5></div></div></div><p>
Each floor is encoded/decoded in channel order, however each floor
belongs to a 'submap' that specifies which floor configuration to
use. All floors are decoded before residue decode begins.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id339179"></a>1.3.2.5.�residue decode</h5></div></div></div><p>
Although the number of residue vectors equals the number of channels,
channel coupling may mean that the raw residue vectors extracted
during decode do not map directly to specific channels. When channel
coupling is in use, some vectors will correspond to coupled magnitude
or angle. The coupling relationships are described in the codec setup
and may differ from frame to frame, due to different mode numbers.</p><p>
Vorbis codes residue vectors in groups by submap; the coding is done
in submap order from submap 0 through n-1. This differs from floors
which are coded using a configuration provided by submap number, but
are coded individually in channel order.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id339196"></a>1.3.2.6.�inverse channel coupling</h5></div></div></div><p>
A detailed discussion of stereo in the Vorbis codec can be found in
the document <a href="stereo.html" target="_top"><em class="citetitle">Stereo Channel Coupling in the
Vorbis CODEC</em></a>. Vorbis is not limited to only stereo coupling, but
the stereo document also gives a good overview of the generic coupling
mechanism.</p><p>
Vorbis coupling applies to pairs of residue vectors at a time;
decoupling is done in-place a pair at a time in the order and using
the vectors specified in the current mapping configuration. The
decoupling operation is the same for all pairs, converting square
polar representation (where one vector is magnitude and the second
angle) back to Cartesian representation.</p><p>
After decoupling, in order, each pair of vectors on the coupling list,
the resulting residue vectors represent the fine spectral detail
of each output channel.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id339224"></a>1.3.2.7.�generate floor curve</h5></div></div></div><p>
The decoder may choose to generate the floor curve at any appropriate
time. It is reasonable to generate the output curve when the floor
data is decoded from the raw packet, or it can be generated after
inverse coupling and applied to the spectral residue directly,
combining generation and the dot product into one step and eliminating
some working space.</p><p>
Both floor 0 and floor 1 generate a linear-range, linear-domain output
vector to be multiplied (dot product) by the linear-range,
linear-domain spectral residue.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id339240"></a>1.3.2.8.�compute floor/residue dot product</h5></div></div></div><p>
This step is straightforward; for each output channel, the decoder
multiplies the floor curve and residue vectors element by element,
producing the finished audio spectrum of each channel.</p><p>
One point is worth mentioning about this dot product; a common mistake
in a fixed point implementation might be to assume that a 32 bit
fixed-point representation for floor and residue and direct
multiplication of the vectors is sufficient for acceptable spectral
depth in all cases because it happens to mostly work with the current
Xiph.Org reference encoder.</p><p>
However, floor vector values can span ~140dB (~24 bits unsigned), and
the audio spectrum vector should represent a minimum of 120dB (~21
bits with sign), even when output is to a 16 bit PCM device. For the
residue vector to represent full scale if the floor is nailed to
-140dB, it must be able to span 0 to +140dB. For the residue vector
to reach full scale if the floor is nailed at 0dB, it must be able to
represent -140dB to +0dB. Thus, in order to handle full range
dynamics, a residue vector may span -140dB to +140dB entirely within
spec. A 280dB range is approximately 48 bits with sign; thus the
residue vector must be able to represent a 48 bit range and the dot
product must be able to handle an effective 48 bit times 24 bit
multiplication. This range may be achieved using large (64 bit or
larger) integers, or implementing a movable binary point
representation.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id339268"></a>1.3.2.9.�inverse monolithic transform (MDCT)</h5></div></div></div><p>
The audio spectrum is converted back into time domain PCM audio via an
inverse Modified Discrete Cosine Transform (MDCT). A detailed
description of the MDCT is available in the paper <a href="http://www.iocon.com/resource/docs/ps/eusipco_corrected.ps" target="_top">&#8220;<span class="citetitle">The use of multirate filter banks for coding of high quality digital
audio</span>&#8221;</a>, by T. Sporer, K. Brandenburg and B. Edler.</p><p>
Note that the PCM produced directly from the MDCT is not yet finished
audio; it must be lapped with surrounding frames using an appropriate
window (such as the Vorbis window) before the MDCT can be considered
orthogonal.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id339292"></a>1.3.2.10.�overlap/add data</h5></div></div></div><p>
Windowed MDCT output is overlapped and added with the right hand data
of the previous window such that the 3/4 point of the previous window
is aligned with the 1/4 point of the current window (as illustrated in
the window overlap diagram). At this point, the audio data between the
center of the previous frame and the center of the current frame is
now finished and ready to be returned. </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id339304"></a>1.3.2.11.�cache right hand data</h5></div></div></div><p>
The decoder must cache the right hand portion of the current frame to
be lapped with the left hand portion of the next frame.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id339314"></a>1.3.2.12.�return finished audio data</h5></div></div></div><p>
The overlapped portion produced from overlapping the previous and
current frame data is finished data to be returned by the decoder.
This data spans from the center of the previous window to the center
of the current window. In the case of same-sized windows, the amount
of data to return is one-half block consisting of and only of the
overlapped portions. When overlapping a short and long window, much of
the returned range is not actually overlap. This does not damage
transform orthogonality. Pay attention however to returning the
correct data range; the amount of data to be returned is:
</p><pre class="programlisting">
window_blocksize(previous_window)/4+window_blocksize(current_window)/4
</pre><p>
from the center of the previous window to the center of the current
window.</p><p>
Data is not returned from the first frame; it must be used to 'prime'
the decode engine. The encoder accounts for this priming when
calculating PCM offsets; after the first frame, the proper PCM output
offset is '0' (as no data has been returned yet).</p></div></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="vorbis-spec-bitpacking"></a>2.�Bitpacking Convention</h2></div><div><p class="releaseinfo">
$Id: 02-bitpacking.xml 7186 2004-07-20 07:19:25Z xiphmont $
</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id304831"></a>2.1.�Overview</h3></div></div></div><p>
The Vorbis codec uses relatively unstructured raw packets containing
arbitrary-width binary integer fields. Logically, these packets are a
bitstream in which bits are coded one-by-one by the encoder and then
read one-by-one in the same monotonically increasing order by the
decoder. Most current binary storage arrangements group bits into a
native word size of eight bits (octets), sixteen bits, thirty-two bits
or, less commonly other fixed word sizes. The Vorbis bitpacking
convention specifies the correct mapping of the logical packet
bitstream into an actual representation in fixed-width words.
</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id304890"></a>2.1.1.�octets, bytes and words</h4></div></div></div><p>
In most contemporary architectures, a 'byte' is synonymous with an
'octet', that is, eight bits. This has not always been the case;
seven, ten, eleven and sixteen bit 'bytes' have been used. For
purposes of the bitpacking convention, a byte implies the native,
smallest integer storage representation offered by a platform. On
modern platforms, this is generally assumed to be eight bits (not
necessarily because of the processor but because of the
filesystem/memory architecture. Modern filesystems invariably offer
bytes as the fundamental atom of storage). A 'word' is an integer
size that is a grouped multiple of this smallest size.</p><p>
The most ubiquitous architectures today consider a 'byte' to be an
octet (eight bits) and a word to be a group of two, four or eight
bytes (16, 32 or 64 bits). Note however that the Vorbis bitpacking
convention is still well defined for any native byte size; Vorbis uses
the native bit-width of a given storage system. This document assumes
that a byte is one octet for purposes of example.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id304832"></a>2.1.2.�bit order</h4></div></div></div><p>
A byte has a well-defined 'least significant' bit (LSb), which is the
only bit set when the byte is storing the two's complement integer
value +1. A byte's 'most significant' bit (MSb) is at the opposite
end of the byte. Bits in a byte are numbered from zero at the LSb to
<span class="emphasis"><em>n</em></span> (<span class="emphasis"><em>n</em></span>=7 in an octet) for the
MSb.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id327953"></a>2.1.3.�byte order</h4></div></div></div><p>
Words are native groupings of multiple bytes. Several byte orderings
are possible in a word; the common ones are 3-2-1-0 ('big endian' or
'most significant byte first' in which the highest-valued byte comes
first), 0-1-2-3 ('little endian' or 'least significant byte first' in
which the lowest value byte comes first) and less commonly 3-1-2-0 and
0-2-1-3 ('mixed endian').</p><p>
The Vorbis bitpacking convention specifies storage and bitstream
manipulation at the byte, not word, level, thus host word ordering is
of a concern only during optimization when writing high performance
code that operates on a word of storage at a time rather than by byte.
Logically, bytes are always coded and decoded in order from byte zero
through byte <span class="emphasis"><em>n</em></span>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id336382"></a>2.1.4.�coding bits into byte sequences</h4></div></div></div><p>
The Vorbis codec has need to code arbitrary bit-width integers, from
zero to 32 bits wide, into packets. These integer fields are not
aligned to the boundaries of the byte representation; the next field
is written at the bit position at which the previous field ends.</p><p>
The encoder logically packs integers by writing the LSb of a binary
integer to the logical bitstream first, followed by next least
significant bit, etc, until the requested number of bits have been
coded. When packing the bits into bytes, the encoder begins by
placing the LSb of the integer to be written into the least
significant unused bit position of the destination byte, followed by
the next-least significant bit of the source integer and so on up to
the requested number of bits. When all bits of the destination byte
have been filled, encoding continues by zeroing all bits of the next
byte and writing the next bit into the bit position 0 of that byte.
Decoding follows the same process as encoding, but by reading bits
from the byte stream and reassembling them into integers.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id310906"></a>2.1.5.�signedness</h4></div></div></div><p>
The signedness of a specific number resulting from decode is to be
interpreted by the decoder given decode context. That is, the three
bit binary pattern 'b111' can be taken to represent either 'seven' as
an unsigned integer, or '-1' as a signed, two's complement integer.
The encoder and decoder are responsible for knowing if fields are to
be treated as signed or unsigned.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258112"></a>2.1.6.�coding example</h4></div></div></div><p>
Code the 4 bit integer value '12' [b1100] into an empty bytestream.
Bytestream result:
</p><pre class="screen">
|
V
7 6 5 4 3 2 1 0
byte 0 [0 0 0 0 1 1 0 0] &lt;-
byte 1 [ ]
byte 2 [ ]
byte 3 [ ]
...
byte n [ ] bytestream length == 1 byte
</pre><p>
</p><p>
Continue by coding the 3 bit integer value '-1' [b111]:
</p><pre class="screen">
|
V
7 6 5 4 3 2 1 0
byte 0 [0 1 1 1 1 1 0 0] &lt;-
byte 1 [ ]
byte 2 [ ]
byte 3 [ ]
...
byte n [ ] bytestream length == 1 byte
</pre><p>
</p><p>
Continue by coding the 7 bit integer value '17' [b0010001]:
</p><pre class="screen">
|
V
7 6 5 4 3 2 1 0
byte 0 [1 1 1 1 1 1 0 0]
byte 1 [0 0 0 0 1 0 0 0] &lt;-
byte 2 [ ]
byte 3 [ ]
...
byte n [ ] bytestream length == 2 bytes
bit cursor == 6
</pre><p>
</p><p>
Continue by coding the 13 bit integer value '6969' [b110 11001110 01]:
</p><pre class="screen">
|
V
7 6 5 4 3 2 1 0
byte 0 [1 1 1 1 1 1 0 0]
byte 1 [0 1 0 0 1 0 0 0]
byte 2 [1 1 0 0 1 1 1 0]
byte 3 [0 0 0 0 0 1 1 0] &lt;-
...
byte n [ ] bytestream length == 4 bytes
</pre><p>
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id258160"></a>2.1.7.�decoding example</h4></div></div></div><p>
Reading from the beginning of the bytestream encoded in the above example:
</p><pre class="screen">
|
V
7 6 5 4 3 2 1 0
byte 0 [1 1 1 1 1 1 0 0] &lt;-
byte 1 [0 1 0 0 1 0 0 0]
byte 2 [1 1 0 0 1 1 1 0]
byte 3 [0 0 0 0 0 1 1 0] bytestream length == 4 bytes
</pre><p>
</p><p>
We read two, two-bit integer fields, resulting in the returned numbers
'b00' and 'b11'. Two things are worth noting here:
</p><div class="itemizedlist"><ul type="disc"><li><p>Although these four bits were originally written as a single
four-bit integer, reading some other combination of bit-widths from the
bitstream is well defined. There are no artificial alignment
boundaries maintained in the bitstream.</p></li><li><p>The second value is the
two-bit-wide integer 'b11'. This value may be interpreted either as
the unsigned value '3', or the signed value '-1'. Signedness is
dependent on decode context.</p></li></ul></div><p>
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id259912"></a>2.1.8.�end-of-packet alignment</h4></div></div></div><p>
The typical use of bitpacking is to produce many independent
byte-aligned packets which are embedded into a larger byte-aligned
container structure, such as an Ogg transport bitstream. Externally,
each bytestream (encoded bitstream) must begin and end on a byte
boundary. Often, the encoded bitstream is not an integer number of
bytes, and so there is unused (uncoded) space in the last byte of a
packet.</p><p>
Unused space in the last byte of a bytestream is always zeroed during
the coding process. Thus, should this unused space be read, it will
return binary zeroes.</p><p>
Attempting to read past the end of an encoded packet results in an
'end-of-packet' condition. End-of-packet is not to be considered an
error; it is merely a state indicating that there is insufficient
remaining data to fulfill the desired read size. Vorbis uses truncated
packets as a normal mode of operation, and as such, decoders must
handle reading past the end of a packet as a typical mode of
operation. Any further read operations after an 'end-of-packet'
condition shall also return 'end-of-packet'.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id259938"></a>2.1.9.� reading zero bits</h4></div></div></div><p>
Reading a zero-bit-wide integer returns the value '0' and does not
increment the stream cursor. Reading to the end of the packet (but
not past, such that an 'end-of-packet' condition has not triggered)
and then reading a zero bit integer shall succeed, returning 0, and
not trigger an end-of-packet condition. Reading a zero-bit-wide
integer after a previous read sets 'end-of-packet' shall also fail
with 'end-of-packet'.</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="vorbis-spec-codebook"></a>3.�Probability Model and Codebooks</h2></div><div><p class="releaseinfo">
$Id: 03-codebook.xml 7186 2004-07-20 07:19:25Z xiphmont $
</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id310158"></a>3.1.�Overview</h3></div></div></div><p>
Unlike practically every other mainstream audio codec, Vorbis has no
statically configured probability model, instead packing all entropy
decoding configuration, VQ and Huffman, into the bitstream itself in
the third header, the codec setup header. This packed configuration
consists of multiple 'codebooks', each containing a specific
Huffman-equivalent representation for decoding compressed codewords as
well as an optional lookup table of output vector values to which a
decoded Huffman value is applied as an offset, generating the final
decoded output corresponding to a given compressed codeword.</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id335318"></a>3.1.1.�Bitwise operation</h4></div></div></div><p>
The codebook mechanism is built on top of the vorbis bitpacker. Both
the codebooks themselves and the codewords they decode are unrolled
from a packet as a series of arbitrary-width values read from the
stream according to <a href="#vorbis-spec-bitpacking" title="2.�Bitpacking Convention">Section�2, &#8220;Bitpacking Convention&#8221;</a>.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id310216"></a>3.2.�Packed codebook format</h3></div></div></div><p>
For purposes of the examples below, we assume that the storage
system's native byte width is eight bits. This is not universally
true; see <a href="#vorbis-spec-bitpacking" title="2.�Bitpacking Convention">Section�2, &#8220;Bitpacking Convention&#8221;</a> for discussion
relating to non-eight-bit bytes.</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id324957"></a>3.2.1.�codebook decode</h4></div></div></div><p>
A codebook begins with a 24 bit sync pattern, 0x564342:
</p><pre class="screen">
byte 0: [ 0 1 0 0 0 0 1 0 ] (0x42)
byte 1: [ 0 1 0 0 0 0 1 1 ] (0x43)
byte 2: [ 0 1 0 1 0 1 1 0 ] (0x56)
</pre><p>
16 bit <code class="varname">[codebook_dimensions]</code> and 24 bit <code class="varname">[codebook_entries]</code> fields:
</p><pre class="screen">
byte 3: [ X X X X X X X X ]
byte 4: [ X X X X X X X X ] [codebook_dimensions] (16 bit unsigned)
byte 5: [ X X X X X X X X ]
byte 6: [ X X X X X X X X ]
byte 7: [ X X X X X X X X ] [codebook_entries] (24 bit unsigned)
</pre><p>
Next is the <code class="varname">[ordered]</code> bit flag:
</p><pre class="screen">
byte 8: [ X ] [ordered] (1 bit)
</pre><p>
Each entry, numbering a
total of <code class="varname">[codebook_entries]</code>, is assigned a codeword length.
We now read the list of codeword lengths and store these lengths in
the array <code class="varname">[codebook_codeword_lengths]</code>. Decode of lengths is
according to whether the <code class="varname">[ordered]</code> flag is set or unset.
</p><div class="itemizedlist"><ul type="disc"><li><p>If the <code class="varname">[ordered]</code> flag is unset, the codeword list is not
length ordered and the decoder needs to read each codeword length
one-by-one.</p><p>The decoder first reads one additional bit flag, the
<code class="varname">[sparse]</code> flag. This flag determines whether or not the
codebook contains unused entries that are not to be included in the
codeword decode tree:
</p><pre class="screen">
byte 8: [ X 1 ] [sparse] flag (1 bit)
</pre><p>
The decoder now performs for each of the <code class="varname">[codebook_entries]</code>
codebook entries:
</p><pre class="screen">
1) if([sparse] is set){
2) [flag] = read one bit;
3) if([flag] is set){
4) [length] = read a five bit unsigned integer;
5) codeword length for this entry is [length]+1;
} else {
6) this entry is unused. mark it as such.
}
} else the sparse flag is not set {
7) [length] = read a five bit unsigned integer;
8) the codeword length for this entry is [length]+1;
}
</pre></li><li><p>If the <code class="varname">[ordered]</code> flag is set, the codeword list for this
codebook is encoded in ascending length order. Rather than reading
a length for every codeword, the encoder reads the number of
codewords per length. That is, beginning at entry zero:
</p><pre class="screen">
1) [current_entry] = 0;
2) [current_length] = read a five bit unsigned integer and add 1;
3) [number] = read <a href="#vorbis-spec-ilog" title="9.2.1.�ilog">ilog</a>([codebook_entries] - [current_entry]) bits as an unsigned integer
4) set the entries [current_entry] through [current_entry]+[number]-1, inclusive,
of the [codebook_codeword_lengths] array to [current_length]
5) set [current_entry] to [number] + [current_entry]
6) increment [current_length] by 1
7) if [current_entry] is greater than [codebook_entries] ERROR CONDITION;
the decoder will not be able to read this stream.
8) if [current_entry] is less than [codebook_entries], repeat process starting at 3)
9) done.
</pre></li></ul></div><p>
After all codeword lengths have been decoded, the decoder reads the
vector lookup table. Vorbis I supports three lookup types:
</p><div class="orderedlist"><ol type="1"><li>No lookup</li><li>Implicitly populated value mapping (lattice VQ)</li><li>Explicitly populated value mapping (tessellated or 'foam'
VQ)</li></ol></div><p>
</p><p>
The lookup table type is read as a four bit unsigned integer:
</p><pre class="screen">
1) [codebook_lookup_type] = read four bits as an unsigned integer
</pre><p>
Codebook decode precedes according to <code class="varname">[codebook_lookup_type]</code>:
</p><div class="itemizedlist"><ul type="disc"><li><p>Lookup type zero indicates no lookup to be read. Proceed past
lookup decode.</p></li><li><p>Lookup types one and two are similar, differing only in the
number of lookup values to be read. Lookup type one reads a list of
values that are permuted in a set pattern to build a list of vectors,
each vector of order <code class="varname">[codebook_dimensions]</code> scalars. Lookup
type two builds the same vector list, but reads each scalar for each
vector explicitly, rather than building vectors from a smaller list of
possible scalar values. Lookup decode proceeds as follows:
</p><pre class="screen">
1) [codebook_minimum_value] = <a href="#vorbis-spec-float32_unpack" title="9.2.2.�float32_unpack">float32_unpack</a>( read 32 bits as an unsigned integer)
2) [codebook_delta_value] = <a href="#vorbis-spec-float32_unpack" title="9.2.2.�float32_unpack">float32_unpack</a>( read 32 bits as an unsigned integer)
3) [codebook_value_bits] = read 4 bits as an unsigned integer and add 1
4) [codebook_sequence_p] = read 1 bit as a boolean flag
if ( [codebook_lookup_type] is 1 ) {
5) [codebook_lookup_values] = <a href="#vorbis-spec-lookup1_values" title="9.2.3.�lookup1_values">lookup1_values</a>(<code class="varname">[codebook_entries]</code>, <code class="varname">[codebook_dimensions]</code> )
} else {
6) [codebook_lookup_values] = <code class="varname">[codebook_entries]</code> * <code class="varname">[codebook_dimensions]</code>
}
7) read a total of [codebook_lookup_values] unsigned integers of [codebook_value_bits] each;
store these in order in the array [codebook_multiplicands]
</pre></li><li><p>A <code class="varname">[codebook_lookup_type]</code> of greater than two is reserved
and indicates a stream that is not decodable by the specification in this
document.</p></li></ul></div><p>
</p><p>
An 'end of packet' during any read operation in the above steps is
considered an error condition rendering the stream undecodable.</p><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id258959"></a>3.2.1.1.�Huffman decision tree representation</h5></div></div></div><p>
The <code class="varname">[codebook_codeword_lengths]</code> array and
<code class="varname">[codebook_entries]</code> value uniquely define the Huffman decision
tree used for entropy decoding.</p><p>
Briefly, each used codebook entry (recall that length-unordered
codebooks support unused codeword entries) is assigned, in order, the
lowest valued unused binary Huffman codeword possible. Assume the
following codeword length list:
</p><pre class="screen">
entry 0: length 2
entry 1: length 4
entry 2: length 4
entry 3: length 4
entry 4: length 4
entry 5: length 2
entry 6: length 3
entry 7: length 3
</pre><p>
Assigning codewords in order (lowest possible value of the appropriate
length to highest) results in the following codeword list:
</p><pre class="screen">
entry 0: length 2 codeword 00
entry 1: length 4 codeword 0100
entry 2: length 4 codeword 0101
entry 3: length 4 codeword 0110
entry 4: length 4 codeword 0111
entry 5: length 2 codeword 10
entry 6: length 3 codeword 110
entry 7: length 3 codeword 111
</pre><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
Unlike most binary numerical values in this document, we
intend the above codewords to be read and used bit by bit from left to
right, thus the codeword '001' is the bit string 'zero, zero, one'.
When determining 'lowest possible value' in the assignment definition
above, the leftmost bit is the MSb.</p></div><p>
It is clear that the codeword length list represents a Huffman
decision tree with the entry numbers equivalent to the leaves numbered
left-to-right:
</p><div class="mediaobject"><img src="hufftree.png" alt="[huffman tree illustration]"></div><p>
</p><p>
As we assign codewords in order, we see that each choice constructs a
new leaf in the leftmost possible position.</p><p>
Note that it's possible to underspecify or overspecify a Huffman tree
via the length list. In the above example, if codeword seven were
eliminated, it's clear that the tree is unfinished:
</p><div class="mediaobject"><img src="hufftree-under.png" alt="[underspecified huffman tree illustration]"></div><p>
</p><p>
Similarly, in the original codebook, it's clear that the tree is fully
populated and a ninth codeword is impossible. Both underspecified and
overspecified trees are an error condition rendering the stream
undecodable.</p><p>
Codebook entries marked 'unused' are simply skipped in the assigning
process. They have no codeword and do not appear in the decision
tree, thus it's impossible for any bit pattern read from the stream to
decode to that entry number.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id316419"></a>3.2.1.2.�VQ lookup table vector representation</h5></div></div></div><p>
Unpacking the VQ lookup table vectors relies on the following values:
</p><pre class="programlisting">
the [codebook_multiplicands] array
[codebook_minimum_value]
[codebook_delta_value]
[codebook_sequence_p]
[codebook_lookup_type]
[codebook_entries]
[codebook_dimensions]
[codebook_lookup_values]
</pre><p>
</p><p>
Decoding (unpacking) a specific vector in the vector lookup table
proceeds according to <code class="varname">[codebook_lookup_type]</code>. The unpacked
vector values are what a codebook would return during audio packet
decode in a VQ context.</p><div class="section" lang="en"><div class="titlepage"><div><div><h6 class="title"><a name="id316444"></a>3.2.1.2.1.�Vector value decode: Lookup type 1</h6></div></div></div><p>
Lookup type one specifies a lattice VQ lookup table built
algorithmically from a list of scalar values. Calculate (unpack) the
final values of a codebook entry vector from the entries in
<code class="varname">[codebook_multiplicands]</code> as follows (<code class="varname">[value_vector]</code>
is the output vector representing the vector of values for entry number
<code class="varname">[lookup_offset]</code> in this codebook):
</p><pre class="screen">
1) [last] = 0;
2) [index_divisor] = 1;
3) iterate [i] over the range 0 ... [codebook_dimensions]-1 (once for each scalar value in the value vector) {
4) [multiplicand_offset] = ( [lookup_offset] divided by [index_divisor] using integer
division ) integer modulo [codebook_lookup_values]
5) vector [value_vector] element [i] =
( [codebook_multiplicands] array element number [multiplicand_offset] ) *
[codebook_delta_value] + [codebook_minimum_value] + [last];
6) if ( [codebook_sequence_p] is set ) then set [last] = vector [value_vector] element [i]
7) [index_divisor] = [index_divisor] * [codebook_lookup_values]
}
8) vector calculation completed.
</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h6 class="title"><a name="id316478"></a>3.2.1.2.2.�Vector value decode: Lookup type 2</h6></div></div></div><p>
Lookup type two specifies a VQ lookup table in which each scalar in
each vector is explicitly set by the <code class="varname">[codebook_multiplicands]</code>
array in a one-to-one mapping. Calculate [unpack] the
final values of a codebook entry vector from the entries in
<code class="varname">[codebook_multiplicands]</code> as follows (<code class="varname">[value_vector]</code>
is the output vector representing the vector of values for entry number
<code class="varname">[lookup_offset]</code> in this codebook):
</p><pre class="screen">
1) [last] = 0;
2) [multiplicand_offset] = [lookup_offset] * [codebook_dimensions]
3) iterate [i] over the range 0 ... [codebook_dimensions]-1 (once for each scalar value in the value vector) {
4) vector [value_vector] element [i] =
( [codebook_multiplicands] array element number [multiplicand_offset] ) *
[codebook_delta_value] + [codebook_minimum_value] + [last];
5) if ( [codebook_sequence_p] is set ) then set [last] = vector [value_vector] element [i]
6) increment [multiplicand_offset]
}
7) vector calculation completed.
</pre></div></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id316518"></a>3.3.�Use of the codebook abstraction</h3></div></div></div><p>
The decoder uses the codebook abstraction much as it does the
bit-unpacking convention; a specific codebook reads a
codeword from the bitstream, decoding it into an entry number, and then
returns that entry number to the decoder (when used in a scalar
entropy coding context), or uses that entry number as an offset into
the VQ lookup table, returning a vector of values (when used in a context
desiring a VQ value). Scalar or VQ context is always explicit; any call
to the codebook mechanism requests either a scalar entry number or a
lookup vector.</p><p>
Note that VQ lookup type zero indicates that there is no lookup table;
requesting decode using a codebook of lookup type 0 in any context
expecting a vector return value (even in a case where a vector of
dimension one) is forbidden. If decoder setup or decode requests such
an action, that is an error condition rendering the packet
undecodable.</p><p>
Using a codebook to read from the packet bitstream consists first of
reading and decoding the next codeword in the bitstream. The decoder
reads bits until the accumulated bits match a codeword in the
codebook. This process can be though of as logically walking the
Huffman decode tree by reading one bit at a time from the bitstream,
and using the bit as a decision boolean to take the 0 branch (left in
the above examples) or the 1 branch (right in the above examples).
Walking the tree finishes when the decode process hits a leaf in the
decision tree; the result is the entry number corresponding to that
leaf. Reading past the end of a packet propagates the 'end-of-stream'
condition to the decoder.</p><p>
When used in a scalar context, the resulting codeword entry is the
desired return value.</p><p>
When used in a VQ context, the codeword entry number is used as an
offset into the VQ lookup table. The value returned to the decoder is
the vector of scalars corresponding to this offset.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="vorbis-spec-codec"></a>4.�Codec Setup and Packet Decode</h2></div><div><p class="releaseinfo">
$Id: 04-codec.xml 10466 2005-11-28 00:34:44Z giles $
</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id336024"></a>4.1.�Overview</h3></div></div></div><p>
This document serves as the top-level reference document for the
bit-by-bit decode specification of Vorbis I. This document assumes a
high-level understanding of the Vorbis decode process, which is
provided in <a href="#vorbis-spec-intro" title="1.�Introduction and Description">Section�1, &#8220;Introduction and Description&#8221;</a>. <a href="#vorbis-spec-bitpacking" title="2.�Bitpacking Convention">Section�2, &#8220;Bitpacking Convention&#8221;</a> covers reading and writing bit fields from
and to bitstream packets.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id326710"></a>4.2.�Header decode and decode setup</h3></div></div></div><p>
A Vorbis bitstream begins with three header packets. The header
packets are, in order, the identification header, the comments header,
and the setup header. All are required for decode compliance. An
end-of-packet condition during decoding the first or third header
packet renders the stream undecodable. End-of-packet decoding the
comment header is a non-fatal error condition.</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id337747"></a>4.2.1.�Common header decode</h4></div></div></div><p>
Each header packet begins with the same header fields.
</p><pre class="screen">
1) [packet_type] : 8 bit value
2) 0x76, 0x6f, 0x72, 0x62, 0x69, 0x73: the characters 'v','o','r','b','i','s' as six octets
</pre><p>
Decode continues according to packet type; the identification header
is type 1, the comment header type 3 and the setup header type 5
(these types are all odd as a packet with a leading single bit of '0'
is an audio packet). The packets must occur in the order of
identification, comment, setup.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id317806"></a>4.2.2.�Identification header</h4></div></div></div><p>
The identification header is a short header of only a few fields used
to declare the stream definitively as Vorbis, and provide a few externally
relevant pieces of information about the audio stream. The
identification header is coded as follows:</p><pre class="screen">
1) [vorbis_version] = read 32 bits as unsigned integer
2) [audio_channels] = read 8 bit integer as unsigned
3) [audio_sample_rate] = read 32 bits as unsigned integer
4) [bitrate_maximum] = read 32 bits as signed integer
5) [bitrate_nominal] = read 32 bits as signed integer
6) [bitrate_minimum] = read 32 bits as signed integer
7) [blocksize_0] = 2 exponent (read 4 bits as unsigned integer)
8) [blocksize_1] = 2 exponent (read 4 bits as unsigned integer)
9) [framing_flag] = read one bit
</pre><p>
<code class="varname">[vorbis_version]</code> is to read '0' in order to be compatible
with this document. Both <code class="varname">[audio_channels]</code> and
<code class="varname">[audio_sample_rate]</code> must read greater than zero. Allowed final
blocksize values are 64, 128, 256, 512, 1024, 2048, 4096 and 8192 in
Vorbis I. <code class="varname">[blocksize_0]</code> must be less than or equal to
<code class="varname">[blocksize_1]</code>. The framing bit must be nonzero. Failure to
meet any of these conditions renders a stream undecodable.</p><p>
The bitrate fields above are used only as hints. The nominal bitrate
field especially may be considerably off in purely VBR streams. The
fields are meaningful only when greater than zero.</p><p>
</p><div class="itemizedlist"><ul type="disc"><li>All three fields set to the same value implies a fixed rate, or tightly bounded, nearly fixed-rate bitstream</li><li>Only nominal set implies a VBR or ABR stream that averages the nominal bitrate</li><li>Maximum and or minimum set implies a VBR bitstream that obeys the bitrate limits</li><li>None set indicates the encoder does not care to speculate.</li></ul></div><p>
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id320370"></a>4.2.3.�Comment header</h4></div></div></div><p>
Comment header decode and data specification is covered in
<a href="#vorbis-spec-comment" title="5.�comment field and header specification">Section�5, &#8220;comment field and header specification&#8221;</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id320384"></a>4.2.4.�Setup header</h4></div></div></div><p>
Vorbis codec setup is configurable to an extreme degree:
</p><div class="mediaobject"><img src="components.png" alt="[decoder pipeline configuration]"></div><p>
</p><p>
The setup header contains the bulk of the codec setup information
needed for decode. The setup header contains, in order, the lists of
codebook configurations, time-domain transform configurations
(placeholders in Vorbis I), floor configurations, residue
configurations, channel mapping configurations and mode
configurations. It finishes with a framing bit of '1'. Header decode
proceeds in the following order:</p><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id305504"></a>4.2.4.1.�Codebooks</h5></div></div></div><div class="orderedlist"><ol type="1"><li><code class="varname">[vorbis_codebook_count]</code> = read eight bits as unsigned integer and add one</li><li>Decode <code class="varname">[vorbis_codebook_count]</code> codebooks in order as defined
in <a href="#vorbis-spec-codebook" title="3.�Probability Model and Codebooks">Section�3, &#8220;Probability Model and Codebooks&#8221;</a>. Save each configuration, in
order, in an array of
codebook configurations <code class="varname">[vorbis_codebook_configurations]</code>.</li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id305539"></a>4.2.4.2.�Time domain transforms</h5></div></div></div><p>
These hooks are placeholders in Vorbis I. Nevertheless, the
configuration placeholder values must be read to maintain bitstream
sync.</p><div class="orderedlist"><ol type="1"><li><code class="varname">[vorbis_time_count]</code> = read 6 bits as unsigned integer and add one</li><li>read <code class="varname">[vorbis_time_count]</code> 16 bit values; each value should be zero. If any value is nonzero, this is an error condition and the stream is undecodable.</li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id328542"></a>4.2.4.3.�Floors</h5></div></div></div><p>
Vorbis uses two floor types; header decode is handed to the decode
abstraction of the appropriate type.</p><div class="orderedlist"><ol type="1"><li><code class="varname">[vorbis_floor_count]</code> = read 6 bits as unsigned integer and add one</li><li><p>For each <code class="varname">[i]</code> of <code class="varname">[vorbis_floor_count]</code> floor numbers:
</p><div class="orderedlist"><ol type="a"><li>read the floor type: vector <code class="varname">[vorbis_floor_types]</code> element <code class="varname">[i]</code> =
read 16 bits as unsigned integer</li><li>If the floor type is zero, decode the floor
configuration as defined in <a href="#vorbis-spec-floor0" title="6.�Floor type 0 setup and decode">Section�6, &#8220;Floor type 0 setup and decode&#8221;</a>; save
this
configuration in slot <code class="varname">[i]</code> of the floor configuration array <code class="varname">[vorbis_floor_configurations]</code>.</li><li>If the floor type is one,
decode the floor configuration as defined in <a href="#vorbis-spec-floor1" title="7.�Floor type 1 setup and decode">Section�7, &#8220;Floor type 1 setup and decode&#8221;</a>; save this configuration in slot <code class="varname">[i]</code> of the floor configuration array <code class="varname">[vorbis_floor_configurations]</code>.</li><li>If the the floor type is greater than one, this stream is undecodable; ERROR CONDITION</li></ol></div><p>
</p></li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id328635"></a>4.2.4.4.�Residues</h5></div></div></div><p>
Vorbis uses three residue types; header decode of each type is identical.
</p><div class="orderedlist"><ol type="1"><li><code class="varname">[vorbis_residue_count]</code> = read 6 bits as unsigned integer and add one
</li><li><p>For each of <code class="varname">[vorbis_residue_count]</code> residue numbers:
</p><div class="orderedlist"><ol type="a"><li>read the residue type; vector <code class="varname">[vorbis_residue_types]</code> element <code class="varname">[i]</code> = read 16 bits as unsigned integer</li><li>If the residue type is zero,
one or two, decode the residue configuration as defined in <a href="#vorbis-spec-residue" title="8.�Residue setup and decode">Section�8, &#8220;Residue setup and decode&#8221;</a>; save this configuration in slot <code class="varname">[i]</code> of the residue configuration array <code class="varname">[vorbis_residue_configurations]</code>.</li><li>If the the residue type is greater than two, this stream is undecodable; ERROR CONDITION</li></ol></div><p>
</p></li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id275059"></a>4.2.4.5.�Mappings</h5></div></div></div><p>
Mappings are used to set up specific pipelines for encoding
multichannel audio with varying channel mapping applications. Vorbis I
uses a single mapping type (0), with implicit PCM channel mappings.</p><div class="orderedlist"><ol type="1"><li><code class="varname">[vorbis_mapping_count]</code> = read 6 bits as unsigned integer and add one</li><li><p>For each <code class="varname">[i]</code> of <code class="varname">[vorbis_mapping_count]</code> mapping numbers:
</p><div class="orderedlist"><ol type="a"><li>read the mapping type: 16 bits as unsigned integer. There's no reason to save the mapping type in Vorbis I.</li><li>If the mapping type is nonzero, the stream is undecodable</li><li><p>If the mapping type is zero:
</p><div class="orderedlist"><ol type="i"><li><p>read 1 bit as a boolean flag
</p><div class="orderedlist"><ol type="A"><li>if set, <code class="varname">[vorbis_mapping_submaps]</code> = read 4 bits as unsigned integer and add one</li><li>if unset, <code class="varname">[vorbis_mapping_submaps]</code> = 1</li></ol></div><p>
</p></li><li><p>read 1 bit as a boolean flag
</p><div class="orderedlist"><ol type="A"><li><p>if set, square polar channel mapping is in use:
</p><div class="orderedlist"><ol type="I"><li><code class="varname">[vorbis_mapping_coupling_steps]</code> = read 8 bits as unsigned integer and add one</li><li><p>for <code class="varname">[j]</code> each of <code class="varname">[vorbis_mapping_coupling_steps]</code> steps:
</p><div class="orderedlist"><ol type="1"><li>vector <code class="varname">[vorbis_mapping_magnitude]</code> element <code class="varname">[j]</code>= read <a href="#vorbis-spec-ilog" title="9.2.1.�ilog">ilog</a>(<code class="varname">[audio_channels]</code> - 1) bits as unsigned integer</li><li>vector <code class="varname">[vorbis_mapping_angle]</code> element <code class="varname">[j]</code>= read <a href="#vorbis-spec-ilog" title="9.2.1.�ilog">ilog</a>(<code class="varname">[audio_channels]</code> - 1) bits as unsigned integer</li><li>the numbers read in the above two steps are channel numbers representing the channel to treat as magnitude and the channel to treat as angle, respectively. If for any coupling step the angle channel number equals the magnitude channel number, the magnitude channel number is greater than <code class="varname">[audio_channels]</code>-1, or the angle channel is greater than <code class="varname">[audio_channels]</code>-1, the stream is undecodable.</li></ol></div><p>
</p></li></ol></div><p>
</p></li><li>if unset, <code class="varname">[vorbis_mapping_coupling_steps]</code> = 0</li></ol></div><p>
</p></li><li>read 2 bits (reserved field); if the value is nonzero, the stream is undecodable</li><li><p>if <code class="varname">[vorbis_mapping_submaps]</code> is greater than one, we read channel multiplex settings. For each <code class="varname">[j]</code> of <code class="varname">[audio_channels]</code> channels:</p><div class="orderedlist"><ol type="A"><li>vector <code class="varname">[vorbis_mapping_mux]</code> element <code class="varname">[j]</code> = read 4 bits as unsigned integer</li><li>if the value is greater than the highest numbered submap (<code class="varname">[vorbis_mapping_submaps]</code> - 1), this in an error condition rendering the stream undecodable</li></ol></div></li><li><p>for each submap <code class="varname">[j]</code> of <code class="varname">[vorbis_mapping_submaps]</code> submaps, read the floor and residue numbers for use in decoding that submap:</p><div class="orderedlist"><ol type="A"><li>read and discard 8 bits (the unused time configuration placeholder)</li><li>read 8 bits as unsigned integer for the floor number; save in vector <code class="varname">[vorbis_mapping_submap_floor]</code> element <code class="varname">[j]</code></li><li>verify the floor number is not greater than the highest number floor configured for the bitstream. If it is, the bitstream is undecodable</li><li>read 8 bits as unsigned integer for the residue number; save in vector <code class="varname">[vorbis_mapping_submap_residue]</code> element <code class="varname">[j]</code></li><li>verify the residue number is not greater than the highest number residue configured for the bitstream. If it is, the bitstream is undecodable</li></ol></div></li><li>save this mapping configuration in slot <code class="varname">[i]</code> of the mapping configuration array <code class="varname">[vorbis_mapping_configurations]</code>.</li></ol></div></li></ol></div><p>
</p></li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id342611"></a>4.2.4.6.�Modes</h5></div></div></div><div class="orderedlist"><ol type="1"><li><code class="varname">[vorbis_mode_count]</code> = read 6 bits as unsigned integer and add one</li><li><p>For each of <code class="varname">[vorbis_mode_count]</code> mode numbers:</p><div class="orderedlist"><ol type="a"><li><code class="varname">[vorbis_mode_blockflag]</code> = read 1 bit</li><li><code class="varname">[vorbis_mode_windowtype]</code> = read 16 bits as unsigned integer</li><li><code class="varname">[vorbis_mode_transformtype]</code> = read 16 bits as unsigned integer</li><li><code class="varname">[vorbis_mode_mapping]</code> = read 8 bits as unsigned integer</li><li>verify ranges; zero is the only legal value in Vorbis I for
<code class="varname">[vorbis_mode_windowtype]</code>
and <code class="varname">[vorbis_mode_transformtype]</code>. <code class="varname">[vorbis_mode_mapping]</code> must not be greater than the highest number mapping in use. Any illegal values render the stream undecodable.</li><li>save this mode configuration in slot <code class="varname">[i]</code> of the mode configuration array
<code class="varname">[vorbis_mode_configurations]</code>.</li></ol></div></li><li>read 1 bit as a framing flag. If unset, a framing error occurred and the stream is not
decodable.</li></ol></div><p>
After reading mode descriptions, setup header decode is complete.
</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id342709"></a>4.3.�Audio packet decode and synthesis</h3></div></div></div><p>
Following the three header packets, all packets in a Vorbis I stream
are audio. The first step of audio packet decode is to read and
verify the packet type. <span class="emphasis"><em>A non-audio packet when audio is expected
indicates stream corruption or a non-compliant stream. The decoder
must ignore the packet and not attempt decoding it to audio</em></span>.
</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id342724"></a>4.3.1.�packet type, mode and window decode</h4></div></div></div><div class="orderedlist"><ol type="1"><li>read 1 bit <code class="varname">[packet_type]</code>; check that packet type is 0 (audio)</li><li>read <a href="#vorbis-spec-ilog" title="9.2.1.�ilog">ilog</a>([vorbis_mode_count]-1) bits
<code class="varname">[mode_number]</code></li><li>decode blocksize <code class="varname">[n]</code> is equal to <code class="varname">[blocksize_0]</code> if
<code class="varname">[vorbis_mode_blockflag]</code> is 0, else <code class="varname">[n]</code> is equal to <code class="varname">[blocksize_1]</code>.</li><li><p>perform window selection and setup; this window is used later by the inverse MDCT:</p><div class="orderedlist"><ol type="a"><li><p>if this is a long window (the <code class="varname">[vorbis_mode_blockflag]</code> flag of this mode is
set):</p><div class="orderedlist"><ol type="i"><li>read 1 bit for <code class="varname">[previous_window_flag]</code></li><li>read 1 bit for <code class="varname">[next_window_flag]</code></li><li>if <code class="varname">[previous_window_flag]</code> is not set, the left half
of the window will be a hybrid window for lapping with a
short block. See <a href="#vorbis-spec-window" title="1.3.2.3.�Window shape decode (long windows only)">Section�1.3.2.3, &#8220;Window shape decode (long windows only)&#8221;</a> for an illustration of overlapping
dissimilar
windows. Else, the left half window will have normal long
shape.</li><li>if <code class="varname">[next_window_flag]</code> is not set, the right half of
the window will be a hybrid window for lapping with a short
block. See <a href="#vorbis-spec-window" title="1.3.2.3.�Window shape decode (long windows only)">Section�1.3.2.3, &#8220;Window shape decode (long windows only)&#8221;</a> for an
illustration of overlapping dissimilar
windows. Else, the left right window will have normal long
shape.</li></ol></div></li><li> if this is a short window, the window is always the same
short-window shape.</li></ol></div></li></ol></div><p>
Vorbis windows all use the slope function y=sin(0.5 * &#960; * sin^2((x+.5)/n * &#960;)),
where n is window size and x ranges 0...n-1, but dissimilar
lapping requirements can affect overall shape. Window generation
proceeds as follows:</p><div class="orderedlist"><ol type="1"><li> <code class="varname">[window_center]</code> = <code class="varname">[n]</code> / 2</li><li><p> if (<code class="varname">[vorbis_mode_blockflag]</code> is set and <code class="varname">[previous_window_flag]</code> is
not set) then
</p><div class="orderedlist"><ol type="a"><li><code class="varname">[left_window_start]</code> = <code class="varname">[n]</code>/4 -
<code class="varname">[blocksize_0]</code>/4</li><li><code class="varname">[left_window_end]</code> = <code class="varname">[n]</code>/4 + <code class="varname">[blocksize_0]</code>/4</li><li><code class="varname">[left_n]</code> = <code class="varname">[blocksize_0]</code>/2</li></ol></div><p>
else
</p><div class="orderedlist"><ol type="a"><li><code class="varname">[left_window_start]</code> = 0</li><li><code class="varname">[left_window_end]</code> = <code class="varname">[window_center]</code></li><li><code class="varname">[left_n]</code> = <code class="varname">[n]</code>/2</li></ol></div></li><li><p> if (<code class="varname">[vorbis_mode_blockflag]</code> is set and <code class="varname">[next_window_flag]</code> is not
set) then
</p><div class="orderedlist"><ol type="a"><li><code class="varname">[right_window_start]</code> = <code class="varname">[n]*3</code>/4 -
<code class="varname">[blocksize_0]</code>/4</li><li><code class="varname">[right_window_end]</code> = <code class="varname">[n]*3</code>/4 +
<code class="varname">[blocksize_0]</code>/4</li><li><code class="varname">[right_n]</code> = <code class="varname">[blocksize_0]</code>/2</li></ol></div><p>
else
</p><div class="orderedlist"><ol type="a"><li><code class="varname">[right_window_start]</code> = <code class="varname">[window_center]</code></li><li><code class="varname">[right_window_end]</code> = <code class="varname">[n]</code></li><li><code class="varname">[right_n]</code> = <code class="varname">[n]</code>/2</li></ol></div></li><li> window from range 0 ... <code class="varname">[left_window_start]</code>-1 inclusive is zero</li><li> for <code class="varname">[i]</code> in range <code class="varname">[left_window_start]</code> ...
<code class="varname">[left_window_end]</code>-1, window(<code class="varname">[i]</code>) = sin(.5 * &#960; * sin^2( (<code class="varname">[i]</code>-<code class="varname">[left_window_start]</code>+.5) / <code class="varname">[left_n]</code> * .5 * &#960;) )</li><li> window from range <code class="varname">[left_window_end]</code> ... <code class="varname">[right_window_start]</code>-1
inclusive is one</li><li> for <code class="varname">[i]</code> in range <code class="varname">[right_window_start]</code> ... <code class="varname">[right_window_end]</code>-1, window(<code class="varname">[i]</code>) = sin(.5 * &#960; * sin^2( (<code class="varname">[i]</code>-<code class="varname">[right_window_start]</code>+.5) / <code class="varname">[right_n]</code> * .5 * &#960; + .5 * &#960;) )</li><li> window from range <code class="varname">[right_window_start]</code> ... <code class="varname">[n]</code>-1 is
zero</li></ol></div><p>
An end-of-packet condition up to this point should be considered an
error that discards this packet from the stream. An end of packet
condition past this point is to be considered a possible nominal
occurrence.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id343132"></a>4.3.2.�floor curve decode</h4></div></div></div><p>
From this point on, we assume out decode context is using mode number
<code class="varname">[mode_number]</code> from configuration array
<code class="varname">[vorbis_mode_configurations]</code> and the map number
<code class="varname">[vorbis_mode_mapping]</code> (specified by the current mode) taken
from the mapping configuration array
<code class="varname">[vorbis_mapping_configurations]</code>.</p><p>
Floor curves are decoded one-by-one in channel order.</p><p>
For each floor <code class="varname">[i]</code> of <code class="varname">[audio_channels]</code>
</p><div class="orderedlist"><ol type="1"><li><code class="varname">[submap_number]</code> = element <code class="varname">[i]</code> of vector [vorbis_mapping_mux]</li><li><code class="varname">[floor_number]</code> = element <code class="varname">[submap_number]</code> of vector
[vorbis_submap_floor]</li><li>if the floor type of this
floor (vector <code class="varname">[vorbis_floor_types]</code> element
<code class="varname">[floor_number]</code>) is zero then decode the floor for
channel <code class="varname">[i]</code> according to the
<a href="#vorbis-spec-floor0-decode" title="6.2.2.�packet decode">Section�6.2.2, &#8220;packet decode&#8221;</a></li><li>if the type of this floor
is one then decode the floor for channel <code class="varname">[i]</code> according
to the <a href="#vorbis-spec-floor1-decode" title="7.2.2.1.�packet decode">Section�7.2.2.1, &#8220;packet decode&#8221;</a></li><li>save the needed decoded floor information for channel for later synthesis</li><li>if the decoded floor returned 'unused', set vector <code class="varname">[no_residue]</code> element
<code class="varname">[i]</code> to true, else set vector <code class="varname">[no_residue]</code> element <code class="varname">[i]</code> to
false</li></ol></div><p>
</p><p>
An end-of-packet condition during floor decode shall result in packet
decode zeroing all channel output vectors and skipping to the
add/overlap output stage.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id343249"></a>4.3.3.�nonzero vector propagate</h4></div></div></div><p>
A possible result of floor decode is that a specific vector is marked
'unused' which indicates that that final output vector is all-zero
values (and the floor is zero). The residue for that vector is not
coded in the stream, save for one complication. If some vectors are
used and some are not, channel coupling could result in mixing a
zeroed and nonzeroed vector to produce two nonzeroed vectors.</p><p>
for each <code class="varname">[i]</code> from 0 ... <code class="varname">[vorbis_mapping_coupling_steps]</code>-1
</p><div class="orderedlist"><ol type="1"><li>if either <code class="varname">[no_residue]</code> entry for channel
(<code class="varname">[vorbis_mapping_magnitude]</code> element <code class="varname">[i]</code>)
or channel
(<code class="varname">[vorbis_mapping_angle]</code> element <code class="varname">[i]</code>)
are set to false, then both must be set to false. Note that an 'unused'
floor has no decoded floor information; it is important that this is
remembered at floor curve synthesis time.</li></ol></div><p>
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id343299"></a>4.3.4.�residue decode</h4></div></div></div><p>
Unlike floors, which are decoded in channel order, the residue vectors
are decoded in submap order.</p><p>
for each submap <code class="varname">[i]</code> in order from 0 ... <code class="varname">[vorbis_mapping_submaps]</code>-1</p><div class="orderedlist"><ol type="1"><li><code class="varname">[ch]</code> = 0</li><li><p>for each channel <code class="varname">[j]</code> in order from 0 ... <code class="varname">[audio_channels]</code> - 1</p><div class="orderedlist"><ol type="a"><li><p>if channel <code class="varname">[j]</code> in submap <code class="varname">[i]</code> (vector <code class="varname">[vorbis_mapping_mux]</code> element <code class="varname">[j]</code> is equal to <code class="varname">[i]</code>)</p><div class="orderedlist"><ol type="i"><li><p>if vector <code class="varname">[no_residue]</code> element <code class="varname">[j]</code> is true
</p><div class="orderedlist"><ol type="A"><li>vector <code class="varname">[do_not_decode_flag]</code> element <code class="varname">[ch]</code> is set</li></ol></div><p>
else
</p><div class="orderedlist"><ol type="A"><li>vector <code class="varname">[do_not_decode_flag]</code> element <code class="varname">[ch]</code> is unset</li></ol></div></li><li>increment <code class="varname">[ch]</code></li></ol></div></li></ol></div></li><li><code class="varname">[residue_number]</code> = vector <code class="varname">[vorbis_mapping_submap_residue]</code> element <code class="varname">[i]</code></li><li><code class="varname">[residue_type]</code> = vector <code class="varname">[vorbis_residue_types]</code> element <code class="varname">[residue_number]</code></li><li>decode <code class="varname">[ch]</code> vectors using residue <code class="varname">[residue_number]</code>, according to type <code class="varname">[residue_type]</code>, also passing vector <code class="varname">[do_not_decode_flag]</code> to indicate which vectors in the bundle should not be decoded. Correct per-vector decode length is <code class="varname">[n]</code>/2.</li><li><code class="varname">[ch]</code> = 0</li><li><p>for each channel <code class="varname">[j]</code> in order from 0 ... <code class="varname">[audio_channels]</code></p><div class="orderedlist"><ol type="a"><li><p>if channel <code class="varname">[j]</code> is in submap <code class="varname">[i]</code> (vector <code class="varname">[vorbis_mapping_mux]</code> element <code class="varname">[j]</code> is equal to <code class="varname">[i]</code>)</p><div class="orderedlist"><ol type="i"><li>residue vector for channel <code class="varname">[j]</code> is set to decoded residue vector <code class="varname">[ch]</code></li><li>increment <code class="varname">[ch]</code></li></ol></div></li></ol></div></li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id343545"></a>4.3.5.�inverse coupling</h4></div></div></div><p>
for each <code class="varname">[i]</code> from <code class="varname">[vorbis_mapping_coupling_steps]</code>-1 descending to 0
</p><div class="orderedlist"><ol type="1"><li><code class="varname">[magnitude_vector]</code> = the residue vector for channel
(vector <code class="varname">[vorbis_mapping_magnitude]</code> element <code class="varname">[i]</code>)</li><li><code class="varname">[angle_vector]</code> = the residue vector for channel (vector
<code class="varname">[vorbis_mapping_angle]</code> element <code class="varname">[i]</code>)</li><li><p>for each scalar value <code class="varname">[M]</code> in vector <code class="varname">[magnitude_vector]</code> and the corresponding scalar value <code class="varname">[A]</code> in vector <code class="varname">[angle_vector]</code>:</p><div class="orderedlist"><ol type="a"><li><p>if (<code class="varname">[M]</code> is greater than zero)
</p><div class="orderedlist"><ol type="i"><li><p>if (<code class="varname">[A]</code> is greater than zero)
</p><div class="orderedlist"><ol type="A"><li><code class="varname">[new_M]</code> = <code class="varname">[M]</code></li><li><code class="varname">[new_A]</code> = <code class="varname">[M]</code>-<code class="varname">[A]</code></li></ol></div><p>
else
</p><div class="orderedlist"><ol type="A"><li><code class="varname">[new_A]</code> = <code class="varname">[M]</code></li><li><code class="varname">[new_M]</code> = <code class="varname">[M]</code>+<code class="varname">[A]</code></li></ol></div><p>
</p></li></ol></div><p>
else
</p><div class="orderedlist"><ol type="i"><li><p>if (<code class="varname">[A]</code> is greater than zero)
</p><div class="orderedlist"><ol type="A"><li><code class="varname">[new_M]</code> = <code class="varname">[M]</code></li><li><code class="varname">[new_A]</code> = <code class="varname">[M]</code>+<code class="varname">[A]</code></li></ol></div><p>
else
</p><div class="orderedlist"><ol type="A"><li><code class="varname">[new_A]</code> = <code class="varname">[M]</code></li><li><code class="varname">[new_M]</code> = <code class="varname">[M]</code>-<code class="varname">[A]</code></li></ol></div><p>
</p></li></ol></div><p>
</p></li><li>set scalar value <code class="varname">[M]</code> in vector <code class="varname">[magnitude_vector]</code> to <code class="varname">[new_M]</code></li><li>set scalar value <code class="varname">[A]</code> in vector <code class="varname">[angle_vector]</code> to <code class="varname">[new_A]</code></li></ol></div></li></ol></div><p>
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id343790"></a>4.3.6.�dot product</h4></div></div></div><p>
For each channel, synthesize the floor curve from the decoded floor
information, according to packet type. Note that the vector synthesis
length for floor computation is <code class="varname">[n]</code>/2.</p><p>
For each channel, multiply each element of the floor curve by each
element of that channel's residue vector. The result is the dot
product of the floor and residue vectors for each channel; the produced
vectors are the length <code class="varname">[n]</code>/2 audio spectrum for each
channel.</p><p>
One point is worth mentioning about this dot product; a common mistake
in a fixed point implementation might be to assume that a 32 bit
fixed-point representation for floor and residue and direct
multiplication of the vectors is sufficient for acceptable spectral
depth in all cases because it happens to mostly work with the current
Xiph.Org reference encoder. </p><p>
However, floor vector values can span ~140dB (~24 bits unsigned), and
the audio spectrum vector should represent a minimum of 120dB (~21
bits with sign), even when output is to a 16 bit PCM device. For the
residue vector to represent full scale if the floor is nailed to
-140dB, it must be able to span 0 to +140dB. For the residue vector
to reach full scale if the floor is nailed at 0dB, it must be able to
represent -140dB to +0dB. Thus, in order to handle full range
dynamics, a residue vector may span -140dB to +140dB entirely within
spec. A 280dB range is approximately 48 bits with sign; thus the
residue vector must be able to represent a 48 bit range and the dot
product must be able to handle an effective 48 bit times 24 bit
multiplication. This range may be achieved using large (64 bit or
larger) integers, or implementing a movable binary point
representation.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id343829"></a>4.3.7.�inverse MDCT</h4></div></div></div><p>
Convert the audio spectrum vector of each channel back into time
domain PCM audio via an inverse Modified Discrete Cosine Transform
(MDCT). A detailed description of the MDCT is available in the paper
<a href="http://www.iocon.com/resource/docs/ps/eusipco_corrected.ps" target="_top">&#8220;<span class="citetitle">The
use of multirate filter banks for coding of high quality digital
audio</span>&#8221;</a>, by T. Sporer, K. Brandenburg and B. Edler. The window
function used for the MDCT is the function described earlier.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id343850"></a>4.3.8.�overlap_add</h4></div></div></div><p>
Windowed MDCT output is overlapped and added with the right hand data
of the previous window such that the 3/4 point of the previous window
is aligned with the 1/4 point of the current window (as illustrated in
<a href="#vorbis-spec-window" title="1.3.2.3.�Window shape decode (long windows only)">Section�1.3.2.3, &#8220;Window shape decode (long windows only)&#8221;</a>). The overlapped portion
produced from overlapping the previous and current frame data is
finished data to be returned by the decoder. This data spans from the
center of the previous window to the center of the current window. In
the case of same-sized windows, the amount of data to return is
one-half block consisting of and only of the overlapped portions. When
overlapping a short and long window, much of the returned range does not
actually overlap. This does not damage transform orthogonality. Pay
attention however to returning the correct data range; the amount of
data to be returned is:
</p><pre class="programlisting">
window_blocksize(previous_window)/4+window_blocksize(current_window)/4
</pre><p>
from the center (element windowsize/2) of the previous window to the
center (element windowsize/2-1, inclusive) of the current window.</p><p>
Data is not returned from the first frame; it must be used to 'prime'
the decode engine. The encoder accounts for this priming when
calculating PCM offsets; after the first frame, the proper PCM output
offset is '0' (as no data has been returned yet).</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id343883"></a>4.3.9.�output channel order</h4></div></div></div><p>
Vorbis I specifies only a channel mapping type 0. In mapping type 0,
channel mapping is implicitly defined as follows for standard audio
applications:</p><div class="variablelist"><dl><dt><span class="term">one channel</span></dt><dd>the stream is monophonic</dd><dt><span class="term">two channels</span></dt><dd>the stream is stereo. channel order: left, right</dd><dt><span class="term">three channels</span></dt><dd>the stream is a 1d-surround encoding. channel order: left,
center, right</dd><dt><span class="term">four channels</span></dt><dd>the stream is quadraphonic surround. channel order: front left,
front right, rear left, rear right</dd><dt><span class="term">five channels</span></dt><dd>the stream is five-channel surround. channel order: front left,
front center, front right, rear left, rear right</dd><dt><span class="term">six channels</span></dt><dd>the stream is 5.1 surround. channel order: front left, front
center, front right, rear left, rear right, LFE</dd><dt><span class="term">greater than six channels</span></dt><dd>channel use and order is defined by the application</dd></dl></div><p>
Applications using Vorbis for dedicated purposes may define channel
mapping as seen fit. Future channel mappings (such as three and four
channel <a href="http://www.ambisonic.net/" target="_top">Ambisonics</a>) will
make use of channel mappings other than mapping 0.</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="vorbis-spec-comment"></a>5.�comment field and header specification</h2></div><div><p class="releaseinfo">
$Id: 05-comment.xml 11703 2006-07-17 16:33:17Z giles $
</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id314030"></a>5.1.�Overview</h3></div></div></div><p>The Vorbis text comment header is the second (of three) header
packets that begin a Vorbis bitstream. It is meant for short text
comments, not arbitrary metadata; arbitrary metadata belongs in a
separate logical bitstream (usually an XML stream type) that provides
greater structure and machine parseability.</p><p>The comment field is meant to be used much like someone jotting a
quick note on the bottom of a CDR. It should be a little information to
remember the disc by and explain it to others; a short, to-the-point
text note that need not only be a couple words, but isn't going to be
more than a short paragraph. The essentials, in other words, whatever
they turn out to be, eg:
</p><div class="blockquote"><blockquote class="blockquote"><p>Honest Bob and the Factory-to-Dealer-Incentives, <em class="citetitle">I'm Still
Around</em>, opening for Moxy Fr�vous, 1997.</p></blockquote></div><p>
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id314058"></a>5.2.�Comment encoding</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id322574"></a>5.2.1.�Structure</h4></div></div></div><p>
The comment header is logically a list of eight-bit-clean vectors; the
number of vectors is bounded to 2^32-1 and the length of each vector
is limited to 2^32-1 bytes. The vector length is encoded; the vector
contents themselves are not null terminated. In addition to the vector
list, there is a single vector for vendor name (also 8 bit clean,
length encoded in 32 bits). For example, the 1.0 release of libvorbis
set the vendor string to "Xiph.Org libVorbis I 20020717".</p><p>The comment header is decoded as follows:
</p><pre class="programlisting">
1) [vendor_length] = read an unsigned integer of 32 bits
2) [vendor_string] = read a UTF-8 vector as [vendor_length] octets
3) [user_comment_list_length] = read an unsigned integer of 32 bits
4) iterate [user_comment_list_length] times {
5) [length] = read an unsigned integer of 32 bits
6) this iteration's user comment = read a UTF-8 vector as [length] octets
}
7) [framing_bit] = read a single bit as boolean
8) if ( [framing_bit] unset or end-of-packet ) then ERROR
9) done.
</pre><p>
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id326883"></a>5.2.2.�Content vector format</h4></div></div></div><p>
The comment vectors are structured similarly to a UNIX environment variable.
That is, comment fields consist of a field name and a corresponding value and
look like:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">
comment[0]="ARTIST=me";
comment[1]="TITLE=the sound of Vorbis";
</pre></blockquote></div><p>
The field name is case-insensitive and may consist of ASCII 0x20
through 0x7D, 0x3D ('=') excluded. ASCII 0x41 through 0x5A inclusive
(characters A-Z) is to be considered equivalent to ASCII 0x61 through
0x7A inclusive (characters a-z).
</p><p>
The field name is immediately followed by ASCII 0x3D ('=');
this equals sign is used to terminate the field name.
</p><p>
0x3D is followed by 8 bit clean UTF-8 encoded value of the
field contents to the end of the field.
</p><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id322620"></a>5.2.2.1.�Field names</h5></div></div></div><p>Below is a proposed, minimal list of standard field names with a
description of intended use. No single or group of field names is
mandatory; a comment header may contain one, all or none of the names
in this list.</p><div class="variablelist"><dl><dt><span class="term">TITLE</span></dt><dd>Track/Work name</dd><dt><span class="term">VERSION</span></dt><dd>The version field may be used to
differentiate multiple
versions of the same track title in a single collection. (e.g. remix
info)
</dd><dt><span class="term">ALBUM</span></dt><dd>The collection name to which this track belongs
</dd><dt><span class="term">TRACKNUMBER</span></dt><dd>The track number of this piece if part of a specific larger collection or album
</dd><dt><span class="term">ARTIST</span></dt><dd>The artist generally considered responsible for the work. In popular music this is usually the performing band or singer. For classical music it would be the composer. For an audio book it would be the author of the original text.
</dd><dt><span class="term">PERFORMER</span></dt><dd>The artist(s) who performed the work. In classical music this would be the conductor, orchestra, soloists. In an audio book it would be the actor who did the reading. In popular music this is typically the same as the ARTIST and is omitted.
</dd><dt><span class="term">COPYRIGHT</span></dt><dd>Copyright attribution, e.g., '2001 Nobody's Band' or '1999 Jack Moffitt'
</dd><dt><span class="term">LICENSE</span></dt><dd>License information, eg, 'All Rights Reserved', 'Any
Use Permitted', a URL to a license such as a Creative Commons license
("www.creativecommons.org/blahblah/license.html") or the EFF Open
Audio License ('distributed under the terms of the Open Audio
License. see http://www.eff.org/IP/Open_licenses/eff_oal.html for
details'), etc.
</dd><dt><span class="term">ORGANIZATION</span></dt><dd>Name of the organization producing the track (i.e.
the 'record label')
</dd><dt><span class="term">DESCRIPTION</span></dt><dd>A short text description of the contents
</dd><dt><span class="term">GENRE</span></dt><dd>A short text indication of music genre
</dd><dt><span class="term">DATE</span></dt><dd>Date the track was recorded
</dd><dt><span class="term">LOCATION</span></dt><dd>Location where track was recorded
</dd><dt><span class="term">CONTACT</span></dt><dd>Contact information for the creators or distributors of the track. This could be a URL, an email address, the physical address of the producing label.
</dd><dt><span class="term">ISRC</span></dt><dd>International Standard Recording Code for the
track; see <a href="http://www.ifpi.org/isrc/" target="_top">the ISRC
intro page</a> for more information on ISRC numbers.
</dd></dl></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="id306349"></a>5.2.2.2.�Implications</h5></div></div></div><p>Field names should not be 'internationalized'; this is a
concession to simplicity not an attempt to exclude the majority of
the world that doesn't speak English. Field <span class="emphasis"><em>contents</em></span>,
however, use the UTF-8 character encoding to allow easy representation
of any language.</p><p>We have the length of the entirety of the field and restrictions on
the field name so that the field name is bounded in a known way. Thus
we also have the length of the field contents.</p><p>Individual 'vendors' may use non-standard field names within
reason. The proper use of comment fields should be clear through
context at this point. Abuse will be discouraged.</p><p>There is no vendor-specific prefix to 'nonstandard' field names.
Vendors should make some effort to avoid arbitrarily polluting the
common namespace. We will generally collect the more useful tags
here to help with standardization.</p><p>Field names are not required to be unique (occur once) within a
comment header. As an example, assume a track was recorded by three
well know artists; the following is permissible, and encouraged:
</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">
ARTIST=Dizzy Gillespie
ARTIST=Sonny Rollins
ARTIST=Sonny Stitt
</pre></blockquote></div><p>
</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id306394"></a>5.2.3.�Encoding</h4></div></div></div><p>
The comment header comprises the entirety of the second bitstream
header packet. Unlike the first bitstream header packet, it is not
generally the only packet on the second page and may not be restricted
to within the second bitstream page. The length of the comment header
packet is (practically) unbounded. The comment header packet is not
optional; it must be present in the bitstream even if it is
effectively empty.</p><p>
The comment header is encoded as follows (as per Ogg's standard
bitstream mapping which renders least-significant-bit of the word to be
coded into the least significant available bit of the current
bitstream octet first):
</p><div class="orderedlist"><ol type="1"><li>
Vendor string length (32 bit unsigned quantity specifying number of octets)
</li><li>
Vendor string ([vendor string length] octets coded from beginning of string to end of string, not null terminated)
</li><li>
Number of comment fields (32 bit unsigned quantity specifying number of fields)
</li><li>
Comment field 0 length (if [Number of comment fields]&gt;0; 32 bit unsigned quantity specifying number of octets)
</li><li>
Comment field 0 ([Comment field 0 length] octets coded from beginning of string to end of string, not null terminated)
</li><li>
Comment field 1 length (if [Number of comment fields]&gt;1...)...
</li></ol></div><p>
</p><p>
This is actually somewhat easier to describe in code; implementation of the above can be found in <code class="filename">vorbis/lib/info.c</code>, <code class="function">_vorbis_pack_comment()</code> and <code class="function">_vorbis_unpack_comment()</code>.
</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="vorbis-spec-floor0"></a>6.�Floor type 0 setup and decode</h2></div><div><p class="releaseinfo">
$Id: 06-floor0.xml 10424 2005-11-23 08:44:18Z xiphmont $
</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id336814"></a>6.1.�Overview</h3></div></div></div><p>
Vorbis floor type zero uses Line Spectral Pair (LSP, also alternately
known as Line Spectral Frequency or LSF) representation to encode a
smooth spectral envelope curve as the frequency response of the LSP
filter. This representation is equivalent to a traditional all-pole
infinite impulse response filter as would be used in linear predictive
coding; LSP representation may be converted to LPC representation and
vice-versa.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id321046"></a>6.2.�Floor 0 format</h3></div></div></div><p>
Floor zero configuration consists of six integer fields and a list of
VQ codebooks for use in coding/decoding the LSP filter coefficient
values used by each frame. </p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id313179"></a>6.2.1.�header decode</h4></div></div></div><p>
Configuration information for instances of floor zero decodes from the
codec setup header (third packet). configuration decode proceeds as
follows:</p><pre class="screen">
1) [floor0_order] = read an unsigned integer of 8 bits
2) [floor0_rate] = read an unsigned integer of 16 bits
3) [floor0_bark_map_size] = read an unsigned integer of 16 bits
4) [floor0_amplitude_bits] = read an unsigned integer of six bits
5) [floor0_amplitude_offset] = read an unsigned integer of eight bits
6) [floor0_number_of_books] = read an unsigned integer of four bits and add 1
7) if any of [floor0_order], [floor0_rate], [floor0_bark_map_size], [floor0_amplitude_bits],
[floor0_amplitude_offset] or [floor0_number_of_books] are less than zero, the stream is not decodable
8) array [floor0_book_list] = read a list of [floor0_number_of_books] unsigned integers of eight bits each;
</pre><p>
An end-of-packet condition during any of these bitstream reads renders
this stream undecodable. In addition, any element of the array
<code class="varname">[floor0_book_list]</code> that is greater than the maximum codebook
number for this bitstream is an error condition that also renders the
stream undecodable.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="vorbis-spec-floor0-decode"></a>6.2.2.�packet decode</h4></div></div></div><p>
Extracting a floor0 curve from an audio packet consists of first
decoding the curve amplitude and <code class="varname">[floor0_order]</code> LSP
coefficient values from the bitstream, and then computing the floor
curve, which is defined as the frequency response of the decoded LSP
filter.</p><p>
Packet decode proceeds as follows:</p><pre class="screen">
1) [amplitude] = read an unsigned integer of [floor0_amplitude_bits] bits
2) if ( [amplitude] is greater than zero ) {
3) [coefficients] is an empty, zero length vector
4) [booknumber] = read an unsigned integer of <a href="#vorbis-spec-ilog" title="9.2.1.�ilog">ilog</a>( [floor0_number_of_books] ) bits
5) if ( [booknumber] is greater than the highest number decode codebook ) then packet is undecodable
6) [last] = zero;
7) vector [temp_vector] = read vector from bitstream using codebook number [floor0_book_list] element [booknumber] in VQ context.
8) add the scalar value [last] to each scalar in vector [temp_vector]
9) [last] = the value of the last scalar in vector [temp_vector]
10) concatenate [temp_vector] onto the end of the [coefficients] vector
11) if (length of vector [coefficients] is less than [floor0_order], continue at step 6
}
12) done.
</pre><p>
Take note of the following properties of decode:
</p><div class="itemizedlist"><ul type="disc"><li>An <code class="varname">[amplitude]</code> value of zero must result in a return code that indicates this channel is unused in this frame (the output of the channel will be all-zeroes in synthesis). Several later stages of decode don't occur for an unused channel.</li><li>An end-of-packet condition during decode should be considered a
nominal occruence; if end-of-packet is reached during any read
operation above, floor decode is to return 'unused' status as if the
<code class="varname">[amplitude]</code> value had read zero at the beginning of decode.</li><li>The book number used for decode
can, in fact, be stored in the bitstream in <a href="#vorbis-spec-ilog" title="9.2.1.�ilog">ilog</a>( <code class="varname">[floor0_number_of_books]</code> -
1 ) bits. Nevertheless, the above specification is correct and values
greater than the maximum possible book value are reserved.</li><li>The number of scalars read into the vector <code class="varname">[coefficients]</code>
may be greater than <code class="varname">[floor0_order]</code>, the number actually
required for curve computation. For example, if the VQ codebook used
for the floor currently being decoded has a
<code class="varname">[codebook_dimensions]</code> value of three and
<code class="varname">[floor0_order]</code> is ten, the only way to fill all the needed
scalars in <code class="varname">[coefficients]</code> is to to read a total of twelve
scalars as four vectors of three scalars each. This is not an error
condition, and care must be taken not to allow a buffer overflow in
decode. The extra values are not used and may be ignored or discarded.</li></ul></div><p>
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="vorbis-spec-floor0-synth"></a>6.2.3.�curve computation</h4></div></div></div><p>
Given an <code class="varname">[amplitude]</code> integer and <code class="varname">[coefficients]</code>
vector from packet decode as well as the [floor0_order],
[floor0_rate], [floor0_bark_map_size], [floor0_amplitude_bits] and
[floor0_amplitude_offset] values from floor setup, and an output
vector size <code class="varname">[n]</code> specified by the decode process, we compute a
floor output vector.</p><p>
If the value <code class="varname">[amplitude]</code> is zero, the return value is a
length <code class="varname">[n]</code> vector with all-zero scalars. Otherwise, begin by
assuming the following definitions for the given vector to be
synthesized:</p><div class="informalequation"><div class="mediaobject"><img src="lspmap.png" alt="[lsp map equation]"></div></div><p>
The above is used to synthesize the LSP curve on a Bark-scale frequency
axis, then map the result to a linear-scale frequency axis.
Similarly, the below calculation synthesizes the output LSP curve <code class="varname">[output]</code> on a log
(dB) amplitude scale, mapping it to linear amplitude in the last step:</p><div class="orderedlist"><ol type="1"><li> <code class="varname">[i]</code> = 0 </li><li><p>if ( <code class="varname">[floor0_order]</code> is odd ) {
</p><div class="orderedlist"><ol type="a"><li><p>calculate <code class="varname">[p]</code> and <code class="varname">[q]</code> according to:
</p><div class="informalequation"><div class="mediaobject"><img src="oddlsp.png" alt="[equation for odd lsp]"></div></div><p>
</p></li></ol></div><p>
} else <code class="varname">[floor0_order]</code> is even {
</p><div class="orderedlist"><ol type="a"><li><p>calculate <code class="varname">[p]</code> and <code class="varname">[q]</code> according to:
</p><div class="informalequation"><div class="mediaobject"><img src="evenlsp.png" alt="[equation for even lsp]"></div></div><p>
</p></li></ol></div><p>
}
</p></li><li><p>calculate <code class="varname">[linear_floor_value]</code> according to:
</p><div class="informalequation"><div class="mediaobject"><img src="floorval.png" alt="[expression for floorval]"></div></div><p>
</p></li><li><code class="varname">[iteration_condition]</code> = map element <code class="varname">[i]</code></li><li><code class="varname">[output]</code> element <code class="varname">[i]</code> = <code class="varname">[linear_floor_value]</code></li><li>increment <code class="varname">[i]</code></li><li>if ( map element <code class="varname">[i]</code> is equal to <code class="varname">[iteration_condition]</code> ) continue at step 5</li><li>if ( <code class="varname">[i]</code> is less than <code class="varname">[n]</code> ) continue at step 2</li><li>done</li></ol></div></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="vorbis-spec-floor1"></a>7.�Floor type 1 setup and decode</h2></div><div><p class="releaseinfo">
$Id: 07-floor1.xml 10466 2005-11-28 00:34:44Z giles $
</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id336243"></a>7.1.�Overview</h3></div></div></div><p>
Vorbis floor type one uses a piecewise straight-line representation to
encode a spectral envelope curve. The representation plots this curve
mechanically on a linear frequency axis and a logarithmic (dB)
amplitude axis. The integer plotting algorithm used is similar to
Bresenham's algorithm.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id334800"></a>7.2.�Floor 1 format</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id316161"></a>7.2.1.�model</h4></div></div></div><p>
Floor type one represents a spectral curve as a series of
line segments. Synthesis constructs a floor curve using iterative
prediction in a process roughly equivalent to the following simplified
description:</p><p>
</p><div class="itemizedlist"><ul type="disc"><li> the first line segment (base case) is a logical line spanning
from x_0,y_0 to x_1,y_1 where in the base case x_0=0 and x_1=[n], the
full range of the spectral floor to be computed.</li><li>the induction step chooses a point x_new within an existing
logical line segment and produces a y_new value at that point computed
from the existing line's y value at x_new (as plotted by the line) and
a difference value decoded from the bitstream packet.</li><li>floor computation produces two new line segments, one running from
x_0,y_0 to x_new,y_new and from x_new,y_new to x_1,y_1. This step is
performed logically even if y_new represents no change to the
amplitude value at x_new so that later refinement is additionally
bounded at x_new.</li><li>the induction step repeats, using a list of x values specified in
the codec setup header at floor 1 initialization time. Computation
is completed at the end of the x value list.</li></ul></div><p>
</p><p>
Consider the following example, with values chosen for ease of
understanding rather than representing typical configuration:</p><p>
For the below example, we assume a floor setup with an [n] of 128.
The list of selected X values in increasing order is
0,16,32,48,64,80,96,112 and 128. In list order, the values interleave
as 0, 128, 64, 32, 96, 16, 48, 80 and 112. The corresponding
list-order Y values as decoded from an example packet are 110, 20, -5,
-45, 0, -25, -10, 30 and -10. We compute the floor in the following
way, beginning with the first line:</p><div class="mediaobject"><img src="floor1-1.png" alt="[graph of example floor]"></div><p>
We now draw new logical lines to reflect the correction to new_Y, and
iterate for X positions 32 and 96:</p><div class="mediaobject"><img src="floor1-2.png" alt="[graph of example floor]"></div><p>
Although the new Y value at X position 96 is unchanged, it is still
used later as an endpoint for further refinement. From here on, the
pattern should be clear; we complete the floor computation as follows:</p><div class="mediaobject"><img src="floor1-3.png" alt="[graph of example floor]"></div><div class="mediaobject"><img src="floor1-4.png" alt="[graph of example floor]"></div><p>
A more efficient algorithm with carefully defined integer rounding
behavior is used for actual decode, as described later. The actual
algorithm splits Y value computation and line plotting into two steps
with modifications to the above algorithm to eliminate noise
accumulation through integer roundoff/truncation. </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id317351"></a>7.2.2.�header decode</h4></div></div></div><p>
A list of floor X values is stored in the packet header in interleaved
format (used in list order during packet decode and synthesis). This
list is split into partitions, and each partition is assigned to a
partition class. X positions 0 and [n] are implicit and do not belong
to an explicit partition or partition class.</p><p>
A partition class consists of a representation vector width (the
number of Y values which the partition class encodes at once), a
'subclass' value representing the number of alternate entropy books
the partition class may use in representing Y values, the list of
[subclass] books and a master book used to encode which alternate
books were chosen for representation in a given packet. The
master/subclass mechanism is meant to be used as a flexible
representation cascade while still using codebooks only in a scalar
context.</p><pre class="screen">
1) [floor1_partitions] = read 5 bits as unsigned integer
2) [maximum_class] = -1
3) iterate [i] over the range 0 ... [floor1_partitions]-1 {
4) vector [floor1_partition_class_list] element [i] = read 4 bits as unsigned integer
}
5) [maximum_class] = largest integer scalar value in vector [floor1_partition_class_list]
6) iterate [i] over the range 0 ... [maximum_class] {
7) vector [floor1_class_dimensions] element [i] = read 3 bits as unsigned integer and add 1
8) vector [floor1_class_subclasses] element [i] = read 2 bits as unsigned integer
9) if ( vector [floor1_class_subclasses] element [i] is nonzero ) {
10) vector [floor1_class_masterbooks] element [i] = read 8 bits as unsigned integer
}
11) iterate [j] over the range 0 ... (2 exponent [floor1_class_subclasses] element [i]) - 1 {
12) array [floor1_subclass_books] element [i],[j] =
read 8 bits as unsigned integer and subtract one
}
}
13) [floor1_multiplier] = read 2 bits as unsigned integer and add one
14) [rangebits] = read 4 bits as unsigned integer
15) vector [floor1_X_list] element [0] = 0
16) vector [floor1_X_list] element [1] = 2 exponent [rangebits];
17) [floor1_values] = 2
18) iterate [i] over the range 0 ... [floor1_partitions]-1 {
19) [current_class_number] = vector [floor1_partition_class_list] element [i]
20) iterate [j] over the range 0 ... ([floor1_class_dimensions] element [current_class_number])-1 {
21) vector [floor1_X_list] element ([floor1_values]) =
read [rangebits] bits as unsigned integer
22) increment [floor1_values] by one
}
}
23) done
</pre><p>
An end-of-packet condition while reading any aspect of a floor 1
configuration during setup renders a stream undecodable. In
addition, a <code class="varname">[floor1_class_masterbooks]</code> or
<code class="varname">[floor1_subclass_books]</code> scalar element greater than the
highest numbered codebook configured in this stream is an error
condition that renders the stream undecodable.</p><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="vorbis-spec-floor1-decode"></a>7.2.2.1.�packet decode</h5></div></div></div><p>
Packet decode begins by checking the <code class="varname">[nonzero]</code> flag:</p><pre class="screen">
1) [nonzero] = read 1 bit as boolean
</pre><p>
If <code class="varname">[nonzero]</code> is unset, that indicates this channel contained
no audio energy in this frame. Decode immediately returns a status
indicating this floor curve (and thus this channel) is unused this
frame. (A return status of 'unused' is different from decoding a
floor that has all points set to minimum representation amplitude,
which happens to be approximately -140dB).
</p><p>
Assuming <code class="varname">[nonzero]</code> is set, decode proceeds as follows:</p><pre class="screen">
1) [range] = vector { 256, 128, 86, 64 } element ([floor1_multiplier]-1)
2) vector [floor1_Y] element [0] = read <a href="#vorbis-spec-ilog" title="9.2.1.�ilog">ilog</a>([range]-1) bits as unsigned integer
3) vector [floor1_Y] element [1] = read <a href="#vorbis-spec-ilog" title="9.2.1.�ilog">ilog</a>([range]-1) bits as unsigned integer
4) [offset] = 2;
5) iterate [i] over the range 0 ... [floor1_partitions]-1 {
6) [class] = vector [floor1_partition_class] element [i]
7) [cdim] = vector [floor1_class_dimensions] element [class]
8) [cbits] = vector [floor1_class_subclasses] element [class]
9) [csub] = (2 exponent [cbits])-1
10) [cval] = 0
11) if ( [cbits] is greater than zero ) {
12) [cval] = read from packet using codebook number
(vector [floor1_class_masterbooks] element [class]) in scalar context
}
13) iterate [j] over the range 0 ... [cdim]-1 {
14) [book] = array [floor1_subclass_books] element [class],([cval] bitwise AND [csub])
15) [cval] = [cval] right shifted [cbits] bits
16) if ( [book] is not less than zero ) {
17) vector [floor1_Y] element ([j]+[offset]) = read from packet using codebook
[book] in scalar context
} else [book] is less than zero {
18) vector [floor1_Y] element ([j]+[offset]) = 0
}
}
19) [offset] = [offset] + [cdim]
}
20) done
</pre><p>
An end-of-packet condition during curve decode should be considered a
nominal occurrence; if end-of-packet is reached during any read
operation above, floor decode is to return 'unused' status as if the
<code class="varname">[nonzero]</code> flag had been unset at the beginning of decode.
</p><p>
Vector <code class="varname">[floor1_Y]</code> contains the values from packet decode
needed for floor 1 synthesis.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="vorbis-spec-floor1-synth"></a>7.2.2.2.�curve computation</h5></div></div></div><p>
Curve computation is split into two logical steps; the first step
derives final Y amplitude values from the encoded, wrapped difference
values taken from the bitstream. The second step plots the curve
lines. Also, although zero-difference values are used in the
iterative prediction to find final Y values, these points are
conditionally skipped during final line computation in step two.
Skipping zero-difference values allows a smoother line fit. </p><p>
Although some aspects of the below algorithm look like inconsequential
optimizations, implementors are warned to follow the details closely.
Deviation from implementing a strictly equivalent algorithm can result
in serious decoding errors.</p><div class="section" lang="en"><div class="titlepage"><div><div><h6 class="title"><a name="id326536"></a>7.2.2.2.1.�step 1: amplitude value synthesis</h6></div></div></div><p>
Unwrap the always-positive-or-zero values read from the packet into
+/- difference values, then apply to line prediction.</p><pre class="screen">
1) [range] = vector { 256, 128, 86, 64 } element ([floor1_multiplier]-1)
2) vector [floor1_step2_flag] element [0] = set
3) vector [floor1_step2_flag] element [1] = set
4) vector [floor1_final_Y] element [0] = vector [floor1_Y] element [0]
5) vector [floor1_final_Y] element [1] = vector [floor1_Y] element [1]
6) iterate [i] over the range 2 ... [floor1_values]-1 {
7) [low_neighbor_offset] = <a href="#vorbis-spec-low_neighbor" title="9.2.4.�low_neighbor">low_neighbor</a>([floor1_X_list],[i])
8) [high_neighbor_offset] = <a href="#vorbis-spec-high_neighbor" title="9.2.4.1.�high_neighbor">high_neighbor</a>([floor1_X_list],[i])
9) [predicted] = <a href="#vorbis-spec-render_point" title="9.2.4.2.�render_point">render_point</a>( vector [floor1_X_list] element [low_neighbor_offset],
vector [floor1_final_Y] element [low_neighbor_offset],
vector [floor1_X_list] element [high_neighbor_offset],
vector [floor1_final_Y] element [high_neighbor_offset],
vector [floor1_X_list] element [i] )
10) [val] = vector [floor1_Y] element [i]
11) [highroom] = [range] - [predicted]
12) [lowroom] = [predicted]
13) if ( [highroom] is less than [lowroom] ) {
14) [room] = [highroom] * 2
} else [highroom] is not less than [lowroom] {
15) [room] = [lowroom] * 2
}
16) if ( [val] is nonzero ) {
17) vector [floor1_step2_flag] element [low_neighbor_offset] = set
18) vector [floor1_step2_flag] element [high_neighbor_offset] = set
19) vector [floor1_step2_flag] element [i] = set
20) if ( [val] is greater than or equal to [room] ) {
21) if ( [highroom] is greater than [lowroom] ) {
22) vector [floor1_final_Y] element [i] = [val] - [lowroom] + [predicted]
} else [highroom] is not greater than [lowroom] {
23) vector [floor1_final_Y] element [i] = [predicted] - [val] + [highroom] - 1
}
} else [val] is less than [room] {
24) if ([val] is odd) {
25) vector [floor1_final_Y] element [i] =
[predicted] - (([val] + 1) divided by 2 using integer division)
} else [val] is even {
26) vector [floor1_final_Y] element [i] =
[predicted] + ([val] / 2 using integer division)
}
}
} else [val] is zero {
27) vector [floor1_step2_flag] element [i] = unset
28) vector [floor1_final_Y] element [i] = [predicted]
}
}
29) done
</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h6 class="title"><a name="id326571"></a>7.2.2.2.2.�step 2: curve synthesis</h6></div></div></div><p>
Curve synthesis generates a return vector <code class="varname">[floor]</code> of length
<code class="varname">[n]</code> (where <code class="varname">[n]</code> is provided by the decode process
calling to floor decode). Floor 1 curve synthesis makes use of the
<code class="varname">[floor1_X_list]</code>, <code class="varname">[floor1_final_Y]</code> and
<code class="varname">[floor1_step2_flag]</code> vectors, as well as [floor1_multiplier]
and [floor1_values] values.</p><p>
Decode begins by sorting the scalars from vectors
<code class="varname">[floor1_X_list]</code>, <code class="varname">[floor1_final_Y]</code> and
<code class="varname">[floor1_step2_flag]</code> together into new vectors
<code class="varname">[floor1_X_list]'</code>, <code class="varname">[floor1_final_Y]'</code> and
<code class="varname">[floor1_step2_flag]'</code> according to ascending sort order of the
values in <code class="varname">[floor1_X_list]</code>. That is, sort the values of
<code class="varname">[floor1_X_list]</code> and then apply the same permutation to
elements of the other two vectors so that the X, Y and step2_flag
values still match.</p><p>
Then compute the final curve in one pass:</p><pre class="screen">
1) [hx] = 0
2) [lx] = 0
3) [ly] = vector [floor1_final_Y]' element [0] * [floor1_multiplier]
4) iterate [i] over the range 1 ... [floor1_values]-1 {
5) if ( [floor1_step2_flag]' element [i] is set ) {
6) [hy] = [floor1_final_Y]' element [i] * [floor1_multiplier]
7) [hx] = [floor1_X_list]' element [i]
8) <a href="#vorbis-spec-render_line" title="9.2.4.3.�render_line">render_line</a>( [lx], [ly], [hx], [hy], [floor] )
9) [lx] = [hx]
10) [ly] = [hy]
}
}
11) if ( [hx] is less than [n] ) {
12) <a href="#vorbis-spec-render_line" title="9.2.4.3.�render_line">render_line</a>( [hx], [hy], [n], [hy], [floor] )
}
13) if ( [hx] is greater than [n] ) {
14) truncate vector [floor] to [n] elements
}
15) for each scalar in vector [floor], perform a lookup substitution using
the scalar value from [floor] as an offset into the vector <a href="#vorbis-spec-floor1_inverse_dB_table" title="10.1.�floor1_inverse_dB_table">[floor1_inverse_dB_static_table]</a>
16) done
</pre></div></div></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="vorbis-spec-residue"></a>8.�Residue setup and decode</h2></div><div><p class="releaseinfo">
$Id: 08-residue.xml 13159 2007-06-21 05:22:35Z xiphmont $
</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id320982"></a>8.1.�Overview</h3></div></div></div><p>
A residue vector represents the fine detail of the audio spectrum of
one channel in an audio frame after the encoder subtracts the floor
curve and performs any channel coupling. A residue vector may
represent spectral lines, spectral magnitude, spectral phase or
hybrids as mixed by channel coupling. The exact semantic content of
the vector does not matter to the residue abstraction.</p><p>
Whatever the exact qualities, the Vorbis residue abstraction codes the
residue vectors into the bitstream packet, and then reconstructs the
vectors during decode. Vorbis makes use of three different encoding
variants (numbered 0, 1 and 2) of the same basic vector encoding
abstraction.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id307154"></a>8.2.�Residue format</h3></div></div></div><p>
Residue format partitions each vector in the vector bundle into chunks,
classifies each chunk, encodes the chunk classifications and finally
encodes the chunks themselves using the the specific VQ arrangement
defined for each selected classification.
The exact interleaving and partitioning vary by residue encoding number,
however the high-level process used to classify and encode the residue
vector is the same in all three variants.</p><p>
A set of coded residue vectors are all of the same length. High level
coding structure, ignoring for the moment exactly how a partition is
encoded and simply trusting that it is, is as follows:</p><p>
</p><div class="itemizedlist"><ul type="disc"><li><p>Each vector is partitioned into multiple equal sized chunks
according to configuration specified. If we have a vector size of
<span class="emphasis"><em>n</em></span>, a partition size <span class="emphasis"><em>residue_partition_size</em></span>, and a total
of <span class="emphasis"><em>ch</em></span> residue vectors, the total number of partitioned chunks
coded is <span class="emphasis"><em>n</em></span>/<span class="emphasis"><em>residue_partition_size</em></span>*<span class="emphasis"><em>ch</em></span>. It is
important to note that the integer division truncates. In the below
example, we assume an example <span class="emphasis"><em>residue_partition_size</em></span> of 8.</p></li><li><p>Each partition in each vector has a classification number that
specifies which of multiple configured VQ codebook setups are used to
decode that partition. The classification numbers of each partition
can be thought of as forming a vector in their own right, as in the
illustration below. Just as the residue vectors are coded in grouped
partitions to increase encoding efficiency, the classification vector
is also partitioned into chunks. The integer elements of each scalar
in a classification chunk are built into a single scalar that
represents the classification numbers in that chunk. In the below
example, the classification codeword encodes two classification
numbers.</p></li><li><p>The values in a residue vector may be encoded monolithically in a
single pass through the residue vector, but more often efficient
codebook design dictates that each vector is encoded as the additive
sum of several passes through the residue vector using more than one
VQ codebook. Thus, each residue value potentially accumulates values
from multiple decode passes. The classification value associated with
a partition is the same in each pass, thus the classification codeword
is coded only in the first pass.</p></li></ul></div><p>
</p><div class="mediaobject"><img src="residue-pack.png" alt="[illustration of residue vector format]"></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id326310"></a>8.3.�residue 0</h3></div></div></div><p>
Residue 0 and 1 differ only in the way the values within a residue
partition are interleaved during partition encoding (visually treated
as a black box--or cyan box or brown box--in the above figure).</p><p>
Residue encoding 0 interleaves VQ encoding according to the
dimension of the codebook used to encode a partition in a specific
pass. The dimension of the codebook need not be the same in multiple
passes, however the partition size must be an even multiple of the
codebook dimension.</p><p>
As an example, assume a partition vector of size eight, to be encoded
by residue 0 using codebook sizes of 8, 4, 2 and 1:</p><pre class="programlisting">
original residue vector: [ 0 1 2 3 4 5 6 7 ]
codebook dimensions = 8 encoded as: [ 0 1 2 3 4 5 6 7 ]
codebook dimensions = 4 encoded as: [ 0 2 4 6 ], [ 1 3 5 7 ]
codebook dimensions = 2 encoded as: [ 0 4 ], [ 1 5 ], [ 2 6 ], [ 3 7 ]
codebook dimensions = 1 encoded as: [ 0 ], [ 1 ], [ 2 ], [ 3 ], [ 4 ], [ 5 ], [ 6 ], [ 7 ]
</pre><p>
It is worth mentioning at this point that no configurable value in the
residue coding setup is restricted to a power of two.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id326344"></a>8.4.�residue 1</h3></div></div></div><p>
Residue 1 does not interleave VQ encoding. It represents partition
vector scalars in order. As with residue 0, however, partition length
must be an integer multiple of the codebook dimension, although
dimension may vary from pass to pass.</p><p>
As an example, assume a partition vector of size eight, to be encoded
by residue 0 using codebook sizes of 8, 4, 2 and 1:</p><pre class="programlisting">
original residue vector: [ 0 1 2 3 4 5 6 7 ]
codebook dimensions = 8 encoded as: [ 0 1 2 3 4 5 6 7 ]
codebook dimensions = 4 encoded as: [ 0 1 2 3 ], [ 4 5 6 7 ]
codebook dimensions = 2 encoded as: [ 0 1 ], [ 2 3 ], [ 4 5 ], [ 6 7 ]
codebook dimensions = 1 encoded as: [ 0 ], [ 1 ], [ 2 ], [ 3 ], [ 4 ], [ 5 ], [ 6 ], [ 7 ]
</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id334893"></a>8.5.�residue 2</h3></div></div></div><p>
Residue type two can be thought of as a variant of residue type 1.
Rather than encoding multiple passed-in vectors as in residue type 1,
the <span class="emphasis"><em>ch</em></span> passed in vectors of length <span class="emphasis"><em>n</em></span> are first
interleaved and flattened into a single vector of length
<span class="emphasis"><em>ch</em></span>*<span class="emphasis"><em>n</em></span>. Encoding then proceeds as in type 1. Decoding is
as in type 1 with decode interleave reversed. If operating on a single
vector to begin with, residue type 1 and type 2 are equivalent.</p><div class="mediaobject"><img src="residue2.png" alt="[illustration of residue type 2]"></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id334939"></a>8.6.�Residue decode</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id334945"></a>8.6.1.�header decode</h4></div></div></div><p>
Header decode for all three residue types is identical.</p><pre class="programlisting">
1) [residue_begin] = read 24 bits as unsigned integer
2) [residue_end] = read 24 bits as unsigned integer
3) [residue_partition_size] = read 24 bits as unsigned integer and add one
4) [residue_classifications] = read 6 bits as unsigned integer and add one
5) [residue_classbook] = read 8 bits as unsigned integer
</pre><p>
<code class="varname">[residue_begin]</code> and <code class="varname">[residue_end]</code> select the specific
sub-portion of each vector that is actually coded; it implements akin
to a bandpass where, for coding purposes, the vector effectively
begins at element <code class="varname">[residue_begin]</code> and ends at
<code class="varname">[residue_end]</code>. Preceding and following values in the unpacked
vectors are zeroed. Note that for residue type 2, these values as
well as <code class="varname">[residue_partition_size]</code>apply to the interleaved
vector, not the individual vectors before interleave.
<code class="varname">[residue_partition_size]</code> is as explained above,
<code class="varname">[residue_classifications]</code> is the number of possible
classification to which a partition can belong and
<code class="varname">[residue_classbook]</code> is the codebook number used to code
classification codewords. The number of dimensions in book
<code class="varname">[residue_classbook]</code> determines how many classification values
are grouped into a single classification codeword.</p><p>
Next we read a bitmap pattern that specifies which partition classes
code values in which passes.</p><pre class="programlisting">
1) iterate [i] over the range 0 ... [residue_classifications]-1 {
2) [high_bits] = 0
3) [low_bits] = read 3 bits as unsigned integer
4) [bitflag] = read one bit as boolean
5) if ( [bitflag] is set ) then [high_bits] = read five bits as unsigned integer
6) vector [residue_cascade] element [i] = [high_bits] * 8 + [low_bits]
}
7) done
</pre><p>
Finally, we read in a list of book numbers, each corresponding to
specific bit set in the cascade bitmap. We loop over the possible
codebook classifications and the maximum possible number of encoding
stages (8 in Vorbis I, as constrained by the elements of the cascade
bitmap being eight bits):</p><pre class="programlisting">
1) iterate [i] over the range 0 ... [residue_classifications]-1 {
2) iterate [j] over the range 0 ... 7 {
3) if ( vector [residue_cascade] element [i] bit [j] is set ) {
4) array [residue_books] element [i][j] = read 8 bits as unsigned integer
} else {
5) array [residue_books] element [i][j] = unused
}
}
}
6) done
</pre><p>
An end-of-packet condition at any point in header decode renders the
stream undecodable. In addition, any codebook number greater than the
maximum numbered codebook set up in this stream also renders the
stream undecodable.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id325037"></a>8.6.2.�packet decode</h4></div></div></div><p>
Format 0 and 1 packet decode is identical except for specific
partition interleave. Format 2 packet decode can be built out of the
format 1 decode process. Thus we describe first the decode
infrastructure identical to all three formats.</p><p>
In addition to configuration information, the residue decode process
is passed the number of vectors in the submap bundle and a vector of
flags indicating if any of the vectors are not to be decoded. If the
passed in number of vectors is 3 and vector number 1 is marked 'do not
decode', decode skips vector 1 during the decode loop. However, even
'do not decode' vectors are allocated and zeroed.</p><p>
Depending on the values of <code class="varname">[residue_begin]</code> and
<code class="varname">[residue_end]</code>, it is obvious that the encoded
portion of a residue vector may be the entire possible residue vector
or some other strict subset of the actual residue vector size with
zero padding at either uncoded end. However, it is also possible to
set <code class="varname">[residue_begin]</code> and
<code class="varname">[residue_end]</code> to specify a range partially or
wholly beyond the maximum vector size. Before beginning residue
decode, limit <code class="varname">[residue_begin]</code> and
<code class="varname">[residue_end]</code> to the maximum possible vector size
as follows. We assume that the number of vectors being encoded,
<code class="varname">[ch]</code> is provided by the higher level decoding
process.</p><pre class="programlisting">
1) [actual_size] = current blocksize/2;
2) if residue encoding is format 2
3) [actual_size] = [actual_size] * [ch];
4) [limit_residue_begin] = maximum of ([residue_begin],[actual_size]);
5) [limit_residue_end] = maximum of ([residue_end],[actual_size]);
</pre><p>
The following convenience values are conceptually useful to clarifying
the decode process:</p><pre class="programlisting">
1) [classwords_per_codeword] = [codebook_dimensions] value of codebook [residue_classbook]
2) [n_to_read] = [limit_residue_end] - [limit_residue_begin]
3) [partitions_to_read] = [n_to_read] / [residue_partition_size]
</pre><p>
Packet decode proceeds as follows, matching the description offered earlier in the document. </p><pre class="programlisting">
1) allocate and zero all vectors that will be returned.
2) if ([n_to_read] is zero), stop; there is no residue to decode.
3) iterate [pass] over the range 0 ... 7 {
4) [partition_count] = 0
5) while [partition_count] is less than [partitions_to_read]
6) if ([pass] is zero) {
7) iterate [j] over the range 0 .. [ch]-1 {
8) if vector [j] is not marked 'do not decode' {
9) [temp] = read from packet using codebook [residue_classbook] in scalar context
10) iterate [i] descending over the range [classwords_per_codeword]-1 ... 0 {
11) array [classifications] element [j],([i]+[partition_count]) =
[temp] integer modulo [residue_classifications]
12) [temp] = [temp] / [residue_classifications] using integer division
}
}
}
}
13) iterate [i] over the range 0 .. ([classwords_per_codeword] - 1) while [partition_count]
is also less than [partitions_to_read] {
14) iterate [j] over the range 0 .. [ch]-1 {
15) if vector [j] is not marked 'do not decode' {
16) [vqclass] = array [classifications] element [j],[partition_count]
17) [vqbook] = array [residue_books] element [vqclass],[pass]
18) if ([vqbook] is not 'unused') {
19) decode partition into output vector number [j], starting at scalar
offset [limit_residue_begin]+[partition_count]*[residue_partition_size] using
codebook number [vqbook] in VQ context
}
}
20) increment [partition_count] by one
}
}
}
21) done
</pre><p>
An end-of-packet condition during packet decode is to be considered a
nominal occurrence. Decode returns the result of vector decode up to
that point.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id341700"></a>8.6.3.�format 0 specifics</h4></div></div></div><p>
Format zero decodes partitions exactly as described earlier in the
'Residue Format: residue 0' section. The following pseudocode
presents the same algorithm. Assume:</p><p>
</p><div class="itemizedlist"><ul type="disc"><li> <code class="varname">[n]</code> is the value in <code class="varname">[residue_partition_size]</code></li><li><code class="varname">[v]</code> is the residue vector</li><li><code class="varname">[offset]</code> is the beginning read offset in [v]</li></ul></div><p>
</p><pre class="programlisting">
1) [step] = [n] / [codebook_dimensions]
2) iterate [i] over the range 0 ... [step]-1 {
3) vector [entry_temp] = read vector from packet using current codebook in VQ context
4) iterate [j] over the range 0 ... [codebook_dimensions]-1 {
5) vector [v] element ([offset]+[i]+[j]*[step]) =
vector [v] element ([offset]+[i]+[j]*[step]) +
vector [entry_temp] element [j]
}
}
6) done
</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id341754"></a>8.6.4.�format 1 specifics</h4></div></div></div><p>
Format 1 decodes partitions exactly as described earlier in the
'Residue Format: residue 1' section. The following pseudocode
presents the same algorithm. Assume:</p><p>
</p><div class="itemizedlist"><ul type="disc"><li> <code class="varname">[n]</code> is the value in
<code class="varname">[residue_partition_size]</code></li><li><code class="varname">[v]</code> is the residue vector</li><li><code class="varname">[offset]</code> is the beginning read offset in [v]</li></ul></div><p>
</p><pre class="programlisting">
1) [i] = 0
2) vector [entry_temp] = read vector from packet using current codebook in VQ context
3) iterate [j] over the range 0 ... [codebook_dimensions]-1 {
4) vector [v] element ([offset]+[i]) =
vector [v] element ([offset]+[i]) +
vector [entry_temp] element [j]
5) increment [i]
}
6) if ( [i] is less than [n] ) continue at step 2
7) done
</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id341807"></a>8.6.5.�format 2 specifics</h4></div></div></div><p>
Format 2 is reducible to format 1. It may be implemented as an additional step prior to and an additional post-decode step after a normal format 1 decode.
</p><p>
Format 2 handles 'do not decode' vectors differently than residue 0 or
1; if all vectors are marked 'do not decode', no decode occurrs.
However, if at least one vector is to be decoded, all the vectors are
decoded. We then request normal format 1 to decode a single vector
representing all output channels, rather than a vector for each
channel. After decode, deinterleave the vector into independent vectors, one for each output channel. That is:</p><div class="orderedlist"><ol type="1"><li>If all vectors 0 through <span class="emphasis"><em>ch</em></span>-1 are marked 'do not decode', allocate and clear a single vector <code class="varname">[v]</code>of length <span class="emphasis"><em>ch*n</em></span> and skip step 2 below; proceed directly to the post-decode step.</li><li>Rather than performing format 1 decode to produce <span class="emphasis"><em>ch</em></span> vectors of length <span class="emphasis"><em>n</em></span> each, call format 1 decode to produce a single vector <code class="varname">[v]</code> of length <span class="emphasis"><em>ch*n</em></span>. </li><li><p>Post decode: Deinterleave the single vector <code class="varname">[v]</code> returned by format 1 decode as described above into <span class="emphasis"><em>ch</em></span> independent vectors, one for each outputchannel, according to:
</p><pre class="programlisting">
1) iterate [i] over the range 0 ... [n]-1 {
2) iterate [j] over the range 0 ... [ch]-1 {
3) output vector number [j] element [i] = vector [v] element ([i] * [ch] + [j])
}
}
4) done
</pre><p>
</p></li></ol></div></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="vorbis-spec-helper"></a>9.�Helper equations</h2></div><div><p class="releaseinfo">
$Id: 09-helper.xml 7186 2004-07-20 07:19:25Z xiphmont $
</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id316603"></a>9.1.�Overview</h3></div></div></div><p>
The equations below are used in multiple places by the Vorbis codec
specification. Rather than cluttering up the main specification
documents, they are defined here and referenced where appropriate.
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id317505"></a>9.2.�Functions</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="vorbis-spec-ilog"></a>9.2.1.�ilog</h4></div></div></div><p>
The "ilog(x)" function returns the position number (1 through n) of the highest set bit in the two's complement integer value
<code class="varname">[x]</code>. Values of <code class="varname">[x]</code> less than zero are defined to return zero.</p><pre class="programlisting">
1) [return_value] = 0;
2) if ( [x] is greater than zero ){
3) increment [return_value];
4) logical shift [x] one bit to the right, padding the MSb with zero
5) repeat at step 2)
}
6) done
</pre><p>
Examples:
</p><div class="itemizedlist"><ul type="disc"><li>ilog(0) = 0;</li><li>ilog(1) = 1;</li><li>ilog(2) = 2;</li><li>ilog(3) = 2;</li><li>ilog(4) = 3;</li><li>ilog(7) = 3;</li><li>ilog(negative number) = 0;</li></ul></div><p>
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="vorbis-spec-float32_unpack"></a>9.2.2.�float32_unpack</h4></div></div></div><p>
"float32_unpack(x)" is intended to translate the packed binary
representation of a Vorbis codebook float value into the
representation used by the decoder for floating point numbers. For
purposes of this example, we will unpack a Vorbis float32 into a
host-native floating point number.</p><pre class="programlisting">
1) [mantissa] = [x] bitwise AND 0x1fffff (unsigned result)
2) [sign] = [x] bitwise AND 0x80000000 (unsigned result)
3) [exponent] = ( [x] bitwise AND 0x7fe00000) shifted right 21 bits (unsigned result)
4) if ( [sign] is nonzero ) then negate [mantissa]
5) return [mantissa] * ( 2 ^ ( [exponent] - 788 ) )
</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="vorbis-spec-lookup1_values"></a>9.2.3.�lookup1_values</h4></div></div></div><p>
"lookup1_values(codebook_entries,codebook_dimensions)" is used to
compute the correct length of the value index for a codebook VQ lookup
table of lookup type 1. The values on this list are permuted to
construct the VQ vector lookup table of size
<code class="varname">[codebook_entries]</code>.</p><p>
The return value for this function is defined to be 'the greatest
integer value for which <code class="varname">[return_value] to the power of
[codebook_dimensions] is less than or equal to
[codebook_entries]</code>'.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="vorbis-spec-low_neighbor"></a>9.2.4.�low_neighbor</h4></div></div></div><p>
"low_neighbor(v,x)" finds the position <code class="varname">n</code> in vector <code class="varname">[v]</code> of
the greatest value scalar element for which <code class="varname">n</code> is less than
<code class="varname">[x]</code> and vector <code class="varname">[v]</code> element <code class="varname">n</code> is less
than vector <code class="varname">[v]</code> element <code class="varname">[x]</code>.</p><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="vorbis-spec-high_neighbor"></a>9.2.4.1.�high_neighbor</h5></div></div></div><p>
"high_neighbor(v,x)" finds the position <code class="varname">n</code> in vector [v] of
the lowest value scalar element for which <code class="varname">n</code> is less than
<code class="varname">[x]</code> and vector <code class="varname">[v]</code> element <code class="varname">n</code> is greater
than vector <code class="varname">[v]</code> element <code class="varname">[x]</code>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="vorbis-spec-render_point"></a>9.2.4.2.�render_point</h5></div></div></div><p>
"render_point(x0,y0,x1,y1,X)" is used to find the Y value at point X
along the line specified by x0, x1, y0 and y1. This function uses an
integer algorithm to solve for the point directly without calculating
intervening values along the line.</p><pre class="programlisting">
1) [dy] = [y1] - [y0]
2) [adx] = [x1] - [x0]
3) [ady] = absolute value of [dy]
4) [err] = [ady] * ([X] - [x0])
5) [off] = [err] / [adx] using integer division
6) if ( [dy] is less than zero ) {
7) [Y] = [y0] - [off]
} else {
8) [Y] = [y0] + [off]
}
9) done
</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="vorbis-spec-render_line"></a>9.2.4.3.�render_line</h5></div></div></div><p>
Floor decode type one uses the integer line drawing algorithm of
"render_line(x0, y0, x1, y1, v)" to construct an integer floor
curve for contiguous piecewise line segments. Note that it has not
been relevant elsewhere, but here we must define integer division as
rounding division of both positive and negative numbers toward zero.
</p><pre class="programlisting">
1) [dy] = [y1] - [y0]
2) [adx] = [x1] - [x0]
3) [ady] = absolute value of [dy]
4) [base] = [dy] / [adx] using integer division
5) [x] = [x0]
6) [y] = [y0]
7) [err] = 0
8) if ( [dy] is less than 0 ) {
9) [sy] = [base] - 1
} else {
10) [sy] = [base] + 1
}
11) [ady] = [ady] - (absolute value of [base]) * [adx]
12) vector [v] element [x] = [y]
13) iterate [x] over the range [x0]+1 ... [x1]-1 {
14) [err] = [err] + [ady];
15) if ( [err] &gt;= [adx] ) {
16) [err] = [err] - [adx]
17) [y] = [y] + [sy]
} else {
18) [y] = [y] + [base]
}
19) vector [v] element [x] = [y]
}
</pre></div></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="vorbis-spec-tables"></a>10.�Tables</h2></div><div><p class="releaseinfo">
$Id: 10-tables.xml 7186 2004-07-20 07:19:25Z xiphmont $
</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="vorbis-spec-floor1_inverse_dB_table"></a>10.1.�floor1_inverse_dB_table</h3></div></div></div><p>
The vector <code class="varname">[floor1_inverse_dB_table]</code> is a 256 element static
lookup table consiting of the following values (read left to right
then top to bottom):</p><pre class="screen">
1.0649863e-07, 1.1341951e-07, 1.2079015e-07, 1.2863978e-07,
1.3699951e-07, 1.4590251e-07, 1.5538408e-07, 1.6548181e-07,
1.7623575e-07, 1.8768855e-07, 1.9988561e-07, 2.1287530e-07,
2.2670913e-07, 2.4144197e-07, 2.5713223e-07, 2.7384213e-07,
2.9163793e-07, 3.1059021e-07, 3.3077411e-07, 3.5226968e-07,
3.7516214e-07, 3.9954229e-07, 4.2550680e-07, 4.5315863e-07,
4.8260743e-07, 5.1396998e-07, 5.4737065e-07, 5.8294187e-07,
6.2082472e-07, 6.6116941e-07, 7.0413592e-07, 7.4989464e-07,
7.9862701e-07, 8.5052630e-07, 9.0579828e-07, 9.6466216e-07,
1.0273513e-06, 1.0941144e-06, 1.1652161e-06, 1.2409384e-06,
1.3215816e-06, 1.4074654e-06, 1.4989305e-06, 1.5963394e-06,
1.7000785e-06, 1.8105592e-06, 1.9282195e-06, 2.0535261e-06,
2.1869758e-06, 2.3290978e-06, 2.4804557e-06, 2.6416497e-06,
2.8133190e-06, 2.9961443e-06, 3.1908506e-06, 3.3982101e-06,
3.6190449e-06, 3.8542308e-06, 4.1047004e-06, 4.3714470e-06,
4.6555282e-06, 4.9580707e-06, 5.2802740e-06, 5.6234160e-06,
5.9888572e-06, 6.3780469e-06, 6.7925283e-06, 7.2339451e-06,
7.7040476e-06, 8.2047000e-06, 8.7378876e-06, 9.3057248e-06,
9.9104632e-06, 1.0554501e-05, 1.1240392e-05, 1.1970856e-05,
1.2748789e-05, 1.3577278e-05, 1.4459606e-05, 1.5399272e-05,
1.6400004e-05, 1.7465768e-05, 1.8600792e-05, 1.9809576e-05,
2.1096914e-05, 2.2467911e-05, 2.3928002e-05, 2.5482978e-05,
2.7139006e-05, 2.8902651e-05, 3.0780908e-05, 3.2781225e-05,
3.4911534e-05, 3.7180282e-05, 3.9596466e-05, 4.2169667e-05,
4.4910090e-05, 4.7828601e-05, 5.0936773e-05, 5.4246931e-05,
5.7772202e-05, 6.1526565e-05, 6.5524908e-05, 6.9783085e-05,
7.4317983e-05, 7.9147585e-05, 8.4291040e-05, 8.9768747e-05,
9.5602426e-05, 0.00010181521, 0.00010843174, 0.00011547824,
0.00012298267, 0.00013097477, 0.00013948625, 0.00014855085,
0.00015820453, 0.00016848555, 0.00017943469, 0.00019109536,
0.00020351382, 0.00021673929, 0.00023082423, 0.00024582449,
0.00026179955, 0.00027881276, 0.00029693158, 0.00031622787,
0.00033677814, 0.00035866388, 0.00038197188, 0.00040679456,
0.00043323036, 0.00046138411, 0.00049136745, 0.00052329927,
0.00055730621, 0.00059352311, 0.00063209358, 0.00067317058,
0.00071691700, 0.00076350630, 0.00081312324, 0.00086596457,
0.00092223983, 0.00098217216, 0.0010459992, 0.0011139742,
0.0011863665, 0.0012634633, 0.0013455702, 0.0014330129,
0.0015261382, 0.0016253153, 0.0017309374, 0.0018434235,
0.0019632195, 0.0020908006, 0.0022266726, 0.0023713743,
0.0025254795, 0.0026895994, 0.0028643847, 0.0030505286,
0.0032487691, 0.0034598925, 0.0036847358, 0.0039241906,
0.0041792066, 0.0044507950, 0.0047400328, 0.0050480668,
0.0053761186, 0.0057254891, 0.0060975636, 0.0064938176,
0.0069158225, 0.0073652516, 0.0078438871, 0.0083536271,
0.0088964928, 0.009474637, 0.010090352, 0.010746080,
0.011444421, 0.012188144, 0.012980198, 0.013823725,
0.014722068, 0.015678791, 0.016697687, 0.017782797,
0.018938423, 0.020169149, 0.021479854, 0.022875735,
0.024362330, 0.025945531, 0.027631618, 0.029427276,
0.031339626, 0.033376252, 0.035545228, 0.037855157,
0.040315199, 0.042935108, 0.045725273, 0.048696758,
0.051861348, 0.055231591, 0.058820850, 0.062643361,
0.066714279, 0.071049749, 0.075666962, 0.080584227,
0.085821044, 0.091398179, 0.097337747, 0.10366330,
0.11039993, 0.11757434, 0.12521498, 0.13335215,
0.14201813, 0.15124727, 0.16107617, 0.17154380,
0.18269168, 0.19456402, 0.20720788, 0.22067342,
0.23501402, 0.25028656, 0.26655159, 0.28387361,
0.30232132, 0.32196786, 0.34289114, 0.36517414,
0.38890521, 0.41417847, 0.44109412, 0.46975890,
0.50028648, 0.53279791, 0.56742212, 0.60429640,
0.64356699, 0.68538959, 0.72993007, 0.77736504,
0.82788260, 0.88168307, 0.9389798, 1.
</pre></div></div><div class="appendix" lang="en"><h2 class="title" style="clear: both"><a name="vorbis-over-ogg"></a>1.�Embedding Vorbis into an Ogg stream</h2><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id319760"></a>1.1.�Overview</h3></div></div></div><p>
This document describes using Ogg logical and physical transport
streams to encapsulate Vorbis compressed audio packet data into file
form.</p><p>
The <a href="#vorbis-spec-intro" title="1.�Introduction and Description">Section�1, &#8220;Introduction and Description&#8221;</a> provides an overview of the construction
of Vorbis audio packets.</p><p>
The <a href="oggstream.html" target="_top">Ogg
bitstream overview</a> and <a href="framing.html" target="_top">Ogg logical
bitstream and framing spec</a> provide detailed descriptions of Ogg
transport streams. This specification document assumes a working
knowledge of the concepts covered in these named backround
documents. Please read them first.</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id336562"></a>1.1.1.�Restrictions</h4></div></div></div><p>
The Ogg/Vorbis I specification currently dictates that Ogg/Vorbis
streams use Ogg transport streams in degenerate, unmultiplexed
form only. That is:
</p><div class="itemizedlist"><ul type="disc"><li>
A meta-headerless Ogg file encapsulates the Vorbis I packets
</li><li>
The Ogg stream may be chained, i.e. contain multiple, contigous logical streams (links).
</li><li>
The Ogg stream must be unmultiplexed (only one stream, a Vorbis audio stream, per link)
</li></ul></div><p>
</p><p>
This is not to say that it is not currently possible to multiplex
Vorbis with other media types into a multi-stream Ogg file. At the
time this document was written, Ogg was becoming a popular container
for low-bitrate movies consisting of DiVX video and Vorbis audio.
However, a 'Vorbis I audio file' is taken to imply Vorbis audio
existing alone within a degenerate Ogg stream. A compliant 'Vorbis
audio player' is not required to implement Ogg support beyond the
specific support of Vorbis within a degenrate ogg stream (naturally,
application authors are encouraged to support full multiplexed Ogg
handling).
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id330723"></a>1.1.2.�MIME type</h4></div></div></div><p>
The correct MIME type of any Ogg file is <code class="literal">application/ogg</code>.
However, if a file is a Vorbis I audio file (which implies a
degenerate Ogg stream including only unmultiplexed Vorbis audio), the
mime type <code class="literal">audio/x-vorbis</code> is also allowed.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id328095"></a>1.2.�Encapsulation</h3></div></div></div><p>
Ogg encapsulation of a Vorbis packet stream is straightforward.</p><div class="itemizedlist"><ul type="disc"><li>
The first Vorbis packet (the identification header), which
uniquely identifies a stream as Vorbis audio, is placed alone in the
first page of the logical Ogg stream. This results in a first Ogg
page of exactly 58 bytes at the very beginning of the logical stream.
</li><li>
This first page is marked 'beginning of stream' in the page flags.
</li><li>
The second and third vorbis packets (comment and setup
headers) may span one or more pages beginning on the second page of
the logical stream. However many pages they span, the third header
packet finishes the page on which it ends. The next (first audio) packet
must begin on a fresh page.
</li><li>
The granule position of these first pages containing only headers is zero.
</li><li>
The first audio packet of the logical stream begins a fresh Ogg page.
</li><li>
Packets are placed into ogg pages in order until the end of stream.
</li><li>
The last page is marked 'end of stream' in the page flags.
</li><li>
Vorbis packets may span page boundaries.
</li><li>
The granule position of pages containing Vorbis audio is in units
of PCM audio samples (per channel; a stereo stream's granule position
does not increment at twice the speed of a mono stream).
</li><li>
The granule position of a page represents the end PCM sample
position of the last packet <span class="emphasis"><em>completed</em></span> on that page.
A page that is entirely spanned by a single packet (that completes on a
subsequent page) has no granule position, and the granule position is
set to '-1'.
</li><li><p>
The granule (PCM) position of the first page need not indicate
that the stream started at position zero. Although the granule
position belongs to the last completed packet on the page and a
valid granule position must be positive, by
inference it may indicate that the PCM position of the beginning
of audio is positive or negative.
</p><div class="itemizedlist"><ul type="circle"><li>
A positive starting value simply indicates that this stream begins at
some positive time offset, potentially within a larger
program. This is a common case when connecting to the middle
of broadcast stream.
</li><li>
A negative value indicates that
output samples preceeding time zero should be discarded during
decoding; this technique is used to allow sample-granularity
editing of the stream start time of already-encoded Vorbis
streams. The number of samples to be discarded must not exceed
the overlap-add span of the first two audio packets.
</li></ul></div><p>
In both of these cases in which the initial audio PCM starting
offset is nonzero, the second finished audio packet must flush the
page on which it appears and the third packet begin a fresh page.
This allows the decoder to always be able to perform PCM position
adjustments before needing to return any PCM data from synthesis,
resulting in correct positioning information without any aditional
seeking logic.
</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
Failure to do so should, at worst, cause a
decoder implementation to return incorrect positioning information
for seeking operations at the very beginning of the stream.
</p></div></li><li>
A granule position on the final page in a stream that indicates
less audio data than the final packet would normally return is used to
end the stream on other than even frame boundaries. The difference
between the actual available data returned and the declared amount
indicates how many trailing samples to discard from the decoding
process.
</li></ul></div></div></div><div class="appendix" lang="en"><h2 class="title" style="clear: both"><a name="vorbis-over-rtp"></a>2.�Vorbis encapsulation in RTP</h2><pre class="literallayout">
<p>Please consult the internet draft <em class="citetitle">RTP Payload Format for Vorbis Encoded
Audio</em> for description of how to embed Vorbis audio in an RTP stream.</p>
</pre></div><div class="appendix" lang="en"><h2 class="title" style="clear: both"><a name="footer"></a>3.�Colophon</h2><div class="mediaobject"><img src="white-xifish.png" alt="[Xiph.org logo]"></div><p>
Ogg is a <a href="http://www.xiph.org/" target="_top">Xiph.org Foundation</a> effort
to protect essential tenets of Internet multimedia from corporate
hostage-taking; Open Source is the net's greatest tool to keep
everyone honest. See <a href="http://www.xiph.org/about.html" target="_top">About
the Xiph.org Foundation</a> for details.
</p><p>
Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and
distribute the Ogg and Vorbis specification, whether in a private,
public or corporate capacity. However, the Xiph.org Foundation and
the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis
specification and certify specification compliance.</p><p>
Xiph.org's Vorbis software CODEC implementation is distributed under a
BSD-like license. This does not restrict third parties from
distributing independent implementations of Vorbis software under
other licenses.</p><p>
Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm)
of the <a href="http://www.xiph.org/" target="_top">Xiph.org Foundation</a>. These
pages are copyright (C) 1994-2004 Xiph.org Foundation. All rights
reserved.</p><p>
This document is set in DocBook XML.
</p></div></div></body></html>

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks