XiphWiki - User contributions [en]

StaticPlayers

2013-04-06T15:49:42Z

Martin.leese: /* Silvercrest (KH 2389, KH 2380, CRB-530 and CRB-631) */ Typo "kays"

== Introduction ==

On this page you can find all static players that are known to support Vorbis. This includes Hi-Fi components such as CD/DVD players and car audio equipment. For hardware that is able to run third-party software (such as PDAs and video game consoles), please visit [[VorbisSoftwarePlayers]].

== Hi-Fi components ==

=== [http://www.playonhd.com/en/#info A.C.Ryan] PlayOn!HD ===
:This player supports a lot of Audio and Video formats, and acts as a player and streamer, Network 10/100, Wifi 802.11b/g, NAS 3.5" SATA up to 1.5TB, 2x USB Host, Internet Radio, HDMI, UPnP client.

=== [http://actiontec.com/products/tech/broadband/wdmp/wdmp_overview.html <del> Actiontec </del>] <del> Wireless Digital Media Player </del> ===
'''Product doesn't exist anymore'''
:This player is a streaming client for video, audio and images. It supports MP3, AC3, AAC, WAV, WMA, Vorbis and internet radio. Supported picture formats are JPEG, GIF, TIF, BMP and PNG. It can play back MPEG-1/-2/-4, Xvid, RMP4. It has RCA connectors, a digital output, supports HDTV and can surf the internet.

=== [http://www.adstech.com/ ADS Tech's] Media-Link ===
:This is a streaming client that uses ethernet and WLAN for connecting. It has a composite, component and s-video out and sterea and S/PDIF out. It supports MPEG-1/-2/-4, DivX, Xvid, MOV, MP3, Vorbis, AC3, WMA, JPG, BMP, GIF. The server software seems to support only windows.

=== [http://www.arcamsolo.com/ ARCAM] DV137, DV139, Solo Movie 5.1 ===
:These high-end British home cinema products are primarily DVD-Video and DVD-Audio playback devices. All support playback of Vorbis, MP3 and WMA files from CD-R and DVD-R discs. Other media supported includes SACD. Audio performance competes with dedicated high-end CD/DVD-A/SACD players whilst video can be upscaled to HD resolutions over HDMI. The DV137 and DV139 are player components whilst the Solo Movie 5.1 is an all-in-one system that includes a DAB/AM/FM radio (territory dependant), various auxiliary inputs and five channels of amplification (5 x 50W RMS into 8 Ohms).

=== [http://www.buffalotech.com/ Buffalo's] PC-P3LWG/DVD ===
:This product is a DVD player and streaming client with HDTV support. It has wireless and wired networking and a USB port. The media server software only runs on Windows (UPnP AV). It supports many formats: video (SVCD/DVD/DivX HD/Xvid/RealMedia/WMV HD), audio (MP3, Vorbis, WAV, AAC, WMA, AC3) and picture (JPG, GIF, BMP, TIF, PNG). It can be integrated with the NAS solution LinkStation/TeraStation for media storage such that no PC is required.

=== [http://www.cyberhome.com/ Cyberhome's] DVD 635s ===

:According to this [http://www.dv-rec.de/test/player2005/635/635.html review(german)] on [http://www.dv-rec.de DV-REC], it plays Vorbis and has '''buggy''' Ogm Video-support. The sound quality appears to be very good(accordimg the review), but there is no special Vorbis point of view about sound quality in the review. Some users report troubling noises from the build in CD/DVD-device.

=== [http://www.digitaltechniques.com/ Digital Technique's] 080S, 160A, 160S, 300A ===
:These are music servers based on PC technology with a capacity from 80 to 300 GB. They support MP3, Vorbis, FLAC and WAV.

=== [http://www.digitalrise.biz/ DigitalRise'] Xstream Player ===
:This item is part of the new generation of DVD players like the Kiss DP-600 and the models from I-O Data and Buffalo -- it can play DVDs, but also WMV-HD DVDs and supports all kinds of audio and video codecs: MPEG-1/-2/-4 (incl. DivX), WMV9, AAC, MP3, WMA and Vorbis.

=== [http://www.dlink.com/ D-Link's] DSM-320 ===
:A wired and wireless UPnP streaming media player. Supports decoding Vorbis as of the 1.03 firmware.

=== [http://www.ethernut.de/en/hardware/eir/ EIR Project] Elektor Internet Radio ===
:Open Source Hardware and Software Project featuring an ARM7 based Internet Radio, which uses VLSI's VS1053 decoder chip.

=== [http://www.hermstedt.de/hifidelio/ Hermstedt's] Hifidelio, Hifidelio Pro ===
:The Hifidelio is a music server in hi-fi format and designed to produce high-quality sound. It uses a CD/DVD combo drive and can thus rip Audio-CDs and read from DVD-Rs, and is also able to burn CDs. It has an in-built 4-port ethernet switch, a WLAN interface, can connect to the iPod and other portable players through USB 2.0. It can connect to other Hifidelios through the UPnP/AV standard and to iTunes shares (iTunes shopping is a future feature). The songs are stored on the 80 GB harddisk. Supported formats for decoding are: MP3, Vorbis, AAC, WMA, FLAC, WAV. The Hifidelio Pro has a 160 GB hdd and some other advanced features.

=== [http://www.iodata.com/ I-O Data's] AVeL LinkPlayer2 ===
:This piece of hardware is a DVD player and a HDTV streaming client. It supports MPEG-2, DivX, XviD and WMV9 (WMV HD), as audio tracks PCM, AC3, MP3, AAC, WMA and Vorbis. It can use ethernet, WLAN and USB 2.0 to connect to media. It is available in Japan from September.

=== [http://www.kenwood.com/ Kenwood's] VRS-N8100, DVF-N7080 ===
:The new line of networked hi-fi components are supposed to decode Vorbis over the Ethernet port: the A/V receiver VRS-N8100 and the DVD player DVF-N7080.

=== [http://www.kiss-technology.com/ KISS Technology's] DVD player models (basically all) ===
:Except for one older model (the DP-330) all DVD/DivX players from Kiss can play Vorbis files from CD-Rs and CD-RWs (but reportedly have trouble with UTF-8 comments that aren’t also ASCII), as well as DivX (but not DivX Vorbis).
:There are reportedly problems with some versions of the firmware (2.6.6 ≤ x < 2.7.1), where playback is awful for a bitrates greater than 128Kb/s.

=== [http://www.medainc.com/ Meda Systems'] Bravo, Bravado ===
:These are media servers with up to 500 GB storage. They can be controlled via PDA and support MP3, WAV, WMA, Vorbis and FLAC. They can also connect to the local network via ethernet.

=== [http://www.xbox.com/ Microsoft's] Xbox ===
:The Xbox is a gaming console based on PC hardware, including a 733 MHz processor, 8 GB harddisk, a DVD drive and an Ethernet port. The console can be [http://waltercedric.com/Mambo/index.php?option=com_content&task=view&id=58&Itemid=40 modded] to allow the installation of third-party software, such as the [http://www.xboxmediacenter.de/ Xbox Media Center] project. Once installed the Xbox becomes a media center and streaming client. It supports vast amounts of audio, video and picture standards, including Vorbis and FLAC.

=== [http://www.mvixusa.com/product.php?product=mx780 Mivx] Wireless Media Player ===
:Does not include a hard drive - you have to supply your own IDE or SATA drive. Supports a wide variety of wireless and component connections and audio/video formats including OGG Vorbis.

=== [http://www.momitsu.com/ Momitsu's] V880N ===
:The V880N is a disc player and streaming client. It supports DVD, VCD/SVCD, Audio CD, Picture CD, MP3, JPEG, DivX, Xvid on discs and MOV, Vorbis, AAC, WMA, AC3 and internet radio over ethernet. In addition to the usual TV connection it supports digital video (DVI) and audio (coaxial/optical) output in HDTV. It has a LAN interface and a PC card slot for a WLAN card.

=== [http://www.mpsharp.com/ MP Sharp Technologies'] Digital Jukebox ===
:The MPST Digital Jukebox is a Linux PC designed for audio playback and sold as a stereo component, which of course can play Vorbis.

=== [http://www.netgem.com Netgem's] iPlayer ===
:The iPlayer is primarily a DVB-T receiver, which includes an in-built modem and can also use a small range of USB ethernet adaptors to connect to a network. Supported media formats include MPEG and MPEG2, MP2 and MP3 and, in the latest release, Vorbis. Technical limitations in the USB controller limit the practical bandwidth of media to around 4 megabits/second. Perhaps the reason for the rather limited range of media formats supported is that the iPlayer is based on low-cost hardware - in the UK Netgem's own branded iPlayer usually retails for around £90. Netgem also host a [http://forum.netgem.com forum]. In addition to the Netgem branded iPlayer in the UK, branded devices are available from other manufacturers such as [http://player.teac.com.au/ Teac] (the ITV-D500, for the Australian market). With the imminent launch of DTT in France, Netgem is also expected to launch a model there.

=== [http://www.neurostechnology.com/ Neuros] [http://www.neurostechnology.com/neuros-osd-specifications OSD] ===
:Hackable, nay, hack-encouraged, open-source streaming media client that plays many video and audio formats, including Vorbis and FLAC.

=== [http://www.neuston.com/ Neuston's] Maestro DVX-1201 ===
:This is a standalone DVD player that supports Vorbis.

=== [http://www.tuxbox.org/ Nokia/Philips/Sagem] DBox2 ===
:This device, manufactured by Nokia, Philips and Sagem until 2002 in huge numbers for the German Pay-TV provider Premiere, is a DVB-C or DVB-S receiver. It features a 10Mbit Ethernet interface and a nifty graphics display. The original software on this device was always a bit flakey. The alternate Linux-based [http://www.tuxbox.org/ Tuxbox] project includes an audio player that perfectly plays Vorbis files from a NFS or CIFS share. Streaming is in beta state.

=== [http://www.olive.us/ Olive Inc's] Musica ===
:This is obviously a relabeled Hifidelio Pro for the US market. For details see the entry of Hermsted.

=== [http://www.uk.onkyo.com/en/products/tx-nr509-35637.html Onkyo] TX-NR509 ===
:This device plays Vorbis and FLAC files from USB sticks/portable drives and has an ethernet connection for streaming audio. I suppose that the other (similar) Onkyo devices, that have these options will play Vorbis / FLAC.

=== [http://support.packardbell.com/uk/item/index.php?m=step2&i=menu_dvd Packard Bell's] DivX 350 DVD, DivX 450 Pro, DVX 460 USB ===
:According to Packard Bell's website these players should all be able to play Vorbis audio files. The 350 model needs to be firmware-upgraded to [http://support.packardbell.com/se/item/index.php?i=instr_releasenotes_fw_divx350pb&pi=platform_divx350pb&dhepn=A000088300 v2.19] to play Vorbis. The 450 Pro exists in three different hardware revisions all of which might not be vorbis enabled.

=== [http://www.phatnoise.com/products/index.php PhatNoise's] Home Player ===
:The Home Digital Media Player uses the same cartridges as the PhatBox, and supports Vorbis out of the box.

=== [http://www.pinnacleaudio.co.uk Pinnacle Audio] Athenaeum ===
:Pinnacle Audio Athenaeum is a high end music server it plays FLAC and Vorbis. It automatically rips CD's to FLAC, but can also encode to Vorbis. It also supports encoding and playing MP3 but does not support DRM.

=== [http://www.philips.com Philips] DVP-5500S/5505 DVD/DIVX/CD/SACD Player ===
:Although it's not written in the manual, this player indeed support Vorbis out of the box (as well as vorbis in an avi container, divx/xvid in an OGM container....) I don't know if there are limitations. I don't understand why it's not advertised.

=== [http://www.p4c.philips.com/cgi-bin/dcbint/cpindex.pl?ctn=DVP5106K/97&slg=en&scy=IN Philips] DVP5106K/97 ===
:This plays Ogg Vorbis audio, even if the manual doesn't say so.

=== [http://www.pinnaclesys.com/ Pinnacle's] ShowCenter 200 ===
:This is a streaming box for audio and video. It supports MPEG-1, MPEG-2, MPEG-2 VOB, MPEG-4 AVI, Xvid, WMV9 and even WMV-HD video. Picture formats are JPEG, BMP, PNG and GIF. The box has native support for MP3, WAV, WMA and Vorbis (the latter requires a software and firmware upgrade to version 2.5, freely available from [http://www.pinnaclesys.com/ Pinnacle]).

=== [http://www.pontis.de/site_e/home_e.htm Pontis'] MediaServer MS300, MS330 ===
:The website stupidly doesn't mention Vorbis support, but it is there, along with MP3. The MS300 is a music server that runs Linux and comes with 80 or whopping 300 GB of storage. It has an ethernet port that lets other desktops access the music via Samba, and supports hardware streaming clients that use the Slimserver protocol ([http://www.slimdevices.com/ Slimdevices], [http://www.rokulabs.com/ Roku]). The USB port and the memory card slot can be used to read in music from portable players and photos from digital cameras. Pictures can be viewed via SCART on the TV. The MS330 is similar to the MS300, but can also burn CDs from the CD drive, has a 6-in-1 memory card slot and supports MP3, Vorbis and FLAC.

=== [http://www.request.com/ ReQuest Multimedia] all products ===
:ReQuest home theatre music systems play FLAC and Vorbis songs, and can edit FLAC and Ogg comments. They can encode CDs to FLAC, and transcode WAV to FLAC, but currently cannot encode to Vorbis. FLAC support has been there for many years; they were one of the first hardware makers to support it. Vorbis support has been there since their 2.0 software release. (They also support MP3 and WAV. They do not support any DRM formats and do not enforce any DRM rules.)

=== [http://www.reson.de/ Reson's] rh1 ===
:The rh1 is a Hifidelio which has been modified for audiophile requirements (new DA component etc).

=== [http://www.rokulabs.com/ Roku's] HD1000, M1000, M2000 ===
:Roku's streaming audio clients support the Slimserver from Slimdevice's products (for details see below).

=== [http://www.skipjam.com/imedia_audio_player.php SkipJam's] iMedia Audio Player, iMedia Audio Player Pro ===
:The iMedia Audio Player is a streaming client with two Ethernet ports and supports MP3, WAV, PCM, WMA, AAC, AC3 FLAC, and Vorbis directly. Through PC-Server software it also plays M4A and M4P. It has two digital (optical/coaxial) and one analog output. The pro version can stream the same formats through ethernet or through built-in Homeplug power line networking, and has a built-in 30W/Chan digital amp. The pro unit is designed for installation in-wall in a 6-gang junction box.

=== [http://www.mysilvercrest.de/ Silvercrest's] KH6510, KH6511, KH6515, KH6516 DVD players ===
:According to [http://www.hdtv-praxis.de/modules.php?op=modload&name=PagEd&file=index&topic_id=2&page_id=151&ppart=2 these (German) reviews], these players can play Vorbis stereo files, but not multichannel files. Silvercrest is a brand of the german discounter LIDL.

=== [http://www.slimdevices.com/ Slim Devices] Squeezebox, Squeezebox2, Squeezebox3, Transporter ===
:The [[wikipedia:Squeezebox network music player|Squeezebox]] is a streaming receiver, that uses LAN or WLAN to stream audio. It supports decoding of MP3 and raw PCM. The server software is open source and available for a number of platforms (Windows, Mac OS X, Linux, FreeBSD) and decodes other formats, like Vorbis and FLAC, on the fly to PCM before streaming. The Squeezebox2 uses the same server software, but can decode FLAC natively, which lowers network traffic for other formats than MP3 considerably. The Squeezebox3 has basically the same features as version 2, but the design has been revamped completely and is more luxurious.

:The Squeezebox3 is advertised with native FLAC and vorbis playback support. With a current firmware update the device plays ogg vorbis streams and tracks of different bit sizes without problems. FLAC playback works as well.

See also:
* [[Wikipedia:Squeezebox_%28network_music_player%29|Wikipedia article about various Squeezebox models]]

=== [http://www.sonos.com/ Sonos'] Multi Zone Digital Music System ===
:Sonos is a complete music system for a house that consists of speakers that are connected wirelessly to a media server. The system also supports Vorbis and FLAC.

=== [http://www.playstation.com/ Sony's] Playstation 2 ===
:The [http://www.trend-express.com/en/medio.html Medio Digital Media Player] transforms the Playstation2 into a streaming client, supporting various audio and video formats, including Vorbis.

=== [http://www.streamit.eu/ Streamit's] Lukas II, SIR120 and SIR120PRO ===
:The Lukas II is a streaming receiver with integrated loudspeaker, that uses LAN or dialup to stream audio. The SIR120 and SIR120PRO are 19" rack mountable streaming receivers with SD card which use LAN to stream audio. All these devices support MP3, WMA, AAC+ and Vorbis streaming.

=== [http://www.my-noxon.com/ Terratec's] Noxon iRadio, Noxon2Radio for iPod, Noxon2Audio. ===
:A WiFi radio for streaming music from the computer and the Internet.

=== [http://www.trans-technology.com/ Transgear's] DVX-500E, DVX-700 M20 ===
:The DVX-500E is a DVD player and streaming client. It supports MPEG-1/-2/DivX/Xvid/VOB/DVB and WAV/MP3/WMA/AAC/Vorbis and JPG/BMP/GIF/TIF/PNG. The DVX-700 can do the same, plus has digital video plugs, supports HD video formats and has a change slot for 3,5" HDDs.

=== [http://www.tversity.com TVersity Media Server]: ===
:A UPNP/AV compliant media server that uses the Vorbis libraries to transcode audio files to the Vorbis format.

=== [http://www.umax.de/ Umax/Yamada] ===
**DVX-6600 For the DVD/DivX player DVX-6600 a future firmware is supposed to be able to decode Vorbis, but there is no release date yet.
**[http://www.umax.de/WebNew/Produkte/9_HomeEntertainment/DVX-6700/DVX-6700.htm DVX-6700]

=== [http://www.watterott.net/projects/webradio-arm WebRadio Project] ===
:Open Source Streaming Client based on an ARM Cortex-M3 microcontroller and VLSI's VS1053 audio codec.

=== [http://www.wdc.com/en/products/products.asp?driveid=572&language=en Western Digital TV] ===
:Also known as WDTV and WD TV. An inexpensive media player, with two USB 2.0 input ports and with HDMI and composite output ports. With the included remote control, device owners can browse the multimedia files contained on the USB devices, through the on-screen menu system. Supports both Ogg Vorbis (tremor-1.0-svn) and FLAC (flac-1.2.1) audio playback, based on WDTV firmware 1.01.01 version. Looks like it runs an embedded Linux operating system and a Motorola ColdFire (ARM) processor.

=== [http://www.yamakawa.de/ Yamakawa's] DVD-375 ===
:The Yamakawa DVD-375 supports Vorbis.

=== [http://www.z500series.com/ Zensonic's] Z500 ===
:The Z500 is a networked multimedia player. It is almost unbelievable how many media types are supported. Video formats: HDTV, DVD, WMV9, DivX, MPEG-1, MPEG-2, MPEG-4, HighMAT, Matroska. Audio formats: Audio CD, MP3, FLAC, Vorbis, AAC, WMA, DVD Audio, and internet radios. Pictures: JPEG, PNG, TIF etc. It supports USB mass storage devices and connects through Gigabit Ethernet or WLAN to the network. The server software runs on Windows, Mac and Linux (UPnP Streaming). Among other connectors it supports the new HDMI standard.

== Car Audio ==

Many of the models below are older types. You may find them second hand. If you add any radio, please add the model introduction year to your description. If you find any type of radio to not be available anymore, please move it to the "Archive" section.

=== Acoustic Solutions ICS-160 ===
:Plays Vorbis, MP3 and WMA from CD, USB and SD card. Can rip from CD/radio/aux to MP3 or WMA, but cannot rip to Vorbis. Displays metadata for MP3, but seems to ignore metadata for Vorbis. (Metadata display not tested for WMA.) Available in UK in [http://www.argos.co.uk/static/Product/partNumber/5005316.htm Spring/Summer 2007 Argos catalogue]. Appears to be based on the same architecture as the Yakumo Hypersound Car Eazy (see above), as the digital display and software appear to be identical, and the two models appear to have identical specifications. However, the design of the fascia is completely different.

=== <del>Alpine CDE-9846R/RM, CDE-9848RB and CDE-111R</del> ===
:'''Cannot play''' Vorbis.
In fact, none of the Alpine can play Vorbis.

=== AudioVox VME 9112 ===
:Plays Vorbis from CD, at least up to q6.

=== Citroën C4 Picasso ===
The brand new Citroën C4 Picasso with usb port can play Ogg Vorbis out of the box. More info [http://service.citroen.com/ddb/donnees/c4picasso/ed01-09/lg_fr_fr/datas/283_285_c4picasso-fr-ed01-2009.pdf here] (in french)

=== <del>[http://www.blaupunkt.com/au/7647573510_main.asp Blaupunkt London MP37]</del> ===
:Cannot play OGG Vorbis files. (In fact, support for Vorbis is ''almost'' present: it can be tricked to play an OGG Vorbis file by putting it into a subdirectory on the CD, but that's it.)

=== [http://www.dension.com Dension] [http://www.dension.com/icelinkgateway300.php ice>Link Gateway 300], [http://www.dension.com/icelinkgateway400.php 400] and [http://www.dension.com/icelinkgateway500.php 500] ===
:Dension develops connected car infotainment systems: Either as a direct stand-alone equipment, or accessory, or complete systems. Either for fitting by the OEM or aftermarket, Dension offers three different (hardware-)gateways to connect either audio players 3.5mm jack), iPods (special connector) or mass storage devices (USB), with the latter having Vorbis files stored on amongst other popular formats. The products are called [http://www.dension.com/icelinkgateway300.php ice>Link Gateway 300], [http://www.dension.com/icelinkgateway400.php 400] and [http://www.dension.com/icelinkgateway500.php 500]; and the support knowledge-base [http://support.dension.com/support-center/index.php?x=&mod_id=2&root=11&id=79 lists all supported formats]. The gateways are compatible to various OEM systems and aftermarket head units, the system used by Volkswagen (see below) may well be supplied by Dension.

=== [http://www.fusioncaraudio.com Fusion] CA-CD500 ===
:Can play Ogg Vorbis from a CD. Website and box say it can play ogg, but manual only mentions MP3/WMA/AAC - don't know why, may be because it (and it's sister unit, the CA-IP500) obviously can't play Ogg from a connected ipod. Plays Ogg very well (tested up to Q8). Downsides are that it does not read metadata, so it will only display folder and file names about each song. Also Ogg playback is not seamless between songs and seems to cause high load, so the display hangs in regular intervals.

=== [http://www.hb-direct.com/ H&B] CA-7475 / CA-7475BTi ===
:This device seems to be similar to the PLU2 P2-106USB, but also has Bluetooth support. It is mainly sold in France, but it is not on H&B's website, so it may be a phased-out model. [http://www.bestofmicro.com/actualite/22493-H-B-CA-7475BTi.html (fr)]

=== [http://www.hb-direct.com/ H&B] CA-7575BTI ===
:[http://www.ldlc.com/fiche/PB00061312.html CA-7575BTI on ldlc website (fr)] this link says that this one is sold out at the moment (2009 05 25)

=== [http://www.hb-direct.com/ H&B] CA-640BTi ===
:CD/CR-R(W), WMA, AAAC, MP3, Ogg Vorbis - ID3 Tag - Bluetooth - USB (also hard disk drive) and SD - iPOD - iPhone - RCA aux
:The capability of playing Ogg Vorbis is documented on the web site of h&b
:[http://www.rueducommerce.fr/Equipement-Automobile-GPS/Autoradios/Autoradios-CD-MP3/H-B/432120-Autoradio-CA-640BTi-CD-MP3-Bluetooth-USB-et-SD-facade-Direct-iPOD-HB.htm CA-640BTi on rueducommerce website (fr)] this one is still available at the moment (2009 05 25)

=== <del>[http://www.hb-direct.com/ H&B] CA-8050BTip</del> ===
:Does '''not''' support OGG Vorbis, even though it has sometimes been advertised to.

=== Hyundai H-CDM8030 ===
:Can play Vorbis from USB flash drive until Q7. Very similar if not identical to Silvercrest CRB-520.

=== [http://www.kenwood.com/ Kenwood's] Music Keg ===
:The [http://www.kenwoodusa.com/products/ListProduct.aspx?k1=2&k2=5&k3=71&pr=2008 Music Keg KHD-C710] uses the same system as the PhatBox below, which means Vorbis support is available. But it seems, that only the software can encode to the HD, but can't play from the Music Keg. [http://www.crutchfieldadvisor.com/S-g2FinmVl7fe/cgi-bin/ProdView.asp?print=Y&g=50800&id=detailed_info&i=113KHDC710]

=== LG models radio (2012) ===
:[http://lg.com LG Electronics] has a range of car audio systems "Smart Car Audio Systems". While their catalog mentions "ogg", only the [http://www.lg.com/in/car-infotainment/dvd-cd-receivers/LG-LDF900UR.jsp LDF900UR] will play it. Other types, like the LCS510IR, LCF610IR, LCS710BR, and LCF810BR do not play Ogg, in spite of several web shops mentioning Ogg support. LG car stereo is not available world wide, only Asia and Middle-East seem to be targeted. However, at least in Germany and Switzerland the LG range is sold by various online shops.

=== [http://origin-community.ministryofsound.com/audio/range.htm Ministry of Sound] [http://shop.ministryofsound.com/Cultures/en-GB/Products/MOSCA104X5.htm?MSCSProfile=9E133C53BD3D92DF1CE9F907D3646C9255036D7AFA803EF7A1C19406E5739EB04CA3BBA8EABD4803AC7F85E26AE78DC143DE377C1060D36EE764E752F8748B9C37DA7AE4DC53D986D49D1C7ADE21AEE447308E31C3159353F77EB0DD5B9A4EA78160B1E4E075A977762313FF570F8494A1229CE23CB601E9992AF7076FC531CC?CatalogNavigationBreadCrumbs=MinistryofSound|Audio|Car_Audio CD tuner] ===
:It is likely that it uses Roadstar electronics as well, because both brands are owned by Alba Plc.

=== [http://www.mutant.uk.com/mt1106mp3.html Mutant MT1106MP3] ===
:Head unit with removable 512MB audio player. Supports Vorbis according to [http://www.ciao.co.uk/Mutant_MT1106USB__Review_5649304 this review].

=== [http://www.parrot.com/catalog/products/parrot-asteroid/ Parrot Asteroid] ===
Parrot is a French company that specializes in wireless products. Their "Asteroid" is a ISO compatible car stereo system with official Ogg support.

=== [http://www.plu2.de/ PLU2] P2-106USB ===
:Plays Vorbis from CD, SD and USB. ebay link on discussion page.

=== [http://www.riocar.org Rio Car] ===
The Rio Car (previously [http://www.empeg.com/ empeg]) is a Linux based harddisk receiver, but was discontinued in 2005. The latest 3.0 alpha software (which was never finished) for this device does support FLAC and gapless Vorbis playback. It may still be the only in-dash device that can hold two 2.5" IDE hard disc drives internally.

=== SENCOR SCD 7405BMR ===
:Can play my ogg files. at least from the usb stick. Even supports tags. From CD, I did not try.
:Interestingly, this feature is not documented by the manufacturer / distributor. Strange ...
:It can play also mp3 and perhaps also wma. It can record also in mp3 format from the fm-radio or even cd.

=== [http://www.roadstar.com/ Roadstar] [http://www.roadstar.com/newsite/index.php?left=family&id=1300&center=productdetail&id_prd=365&right=productdownload&id_fam=113 CD-258US/512] ===
:Car CD tuner with MP3 / WMA / Vorbis disc playback and a detachable front panel with internal Flash memory of 512 MB. Upload via USB from your PC your favourite songs to the internal memory inside the detachable panel (MP3, WMA or Vorbis file format). Encode your music in MP3 format from CD / Radio / Aux-In source to the Internal Flash Memory or USB / SD / MMC. Transfer your favourite MP3 / WMA / Vorbis files between CD disc / Internal Flash Memory / USB / SD / MMC.
:It displays no ID3 info on Ogg files, but it constantly displays stats and filename about the currently-playing file.

=== [http://www.roadstar.com/ Roadstar] CD-656USWM/FM ===
:Although neither the manual, nor the package or the inscriptions on the front panel mention Ogg Vorbis, it does play Ogg Vorbis files fine (the manual and the package only state that it can play MP3 and WMA files, but obviously this is not the whole truth).
:It plays Ogg Vorbis files both via CD/CD-R/CD-RW, via USB and via SD/MMC. It only displays the filename, the bitrate and the sampling rate during playback.

=== SEAT Ibiza (Model 6J) ===
:The new SEAT Ibiza model, current as of 2009, offers a car hifi system with USB port as an option. If present, the following file types can be played via USB: MP3, WMA, AAC (in MP4 container and bitstream-only, possible extensions are .MP4, .M4A and .AAC) ''and'' Ogg Vorbis, too. For all file types, metadata is displayed (Vorbis comments, ID3 tags, MP4 file info etc.). The manual for the built-in stereo only mentions "MP3, WMA and AAC"...

=== [http://www.mysilvercrest.de Silvercrest] ([http://www.mysilvercrest.de/en/artikel.php?a=62 KH 2389], [http://www.mysilvercrest.de/en/artikel.php?a=98 KH 2380], [http://www.mysilvercrest.de/en/artikel.php?a=127 CRB-530] and CRB-631) ===
In-dash CD-MP3-Players. It is possible to plug in a USB stick and SD card into them. Vorbis works with the USB stick, SD card and CD. Silvercrest is a brand of the german discounter LIDL.

Although LIDL's advertisement for the KH 2380 in December 2006 made a show of its Vorbis support, this is not mentioned in the manual, or any accompanying documentation. Initial impressions suggest that playback for q3 is good, and correctly plays the entire track, but is not gapless.

* [http://www.lidl-service.com/cps/rde/xchg/SID-F19E0035-5CD53BA8/lsp/hs.xsl/product.html?id=41334046&title=Car+Radio&count=1 SAR 28 A1] (2013) officially read MP3 and WMA but can also read ogg vorbis (after a very quick test. but not able to read FLAC)
* [http://www.mysilvercrest.de/en/artikel.php?a=127 CRB-530] has a documented compatibility with ogg. The ogg is fluid.
* [http://www.mysilvercrest.de/en/artikel.php?a=139 CRB-531] is identical, but comes without the ISO adapter cable.
* [http://www.mysilvercrest.de/en/artikel.php?a=126 CRE-520] is similar, but without the Bluetooth feature.
* CRB-631 a successor of CRB-531 has full numeric keyboard and dedicated Accept/Reject keys for better phone communication
I haven't found any official site, but [http://www.ebay.de/itm/CD-Autoradio-CRB-631-SilverCrest-USB-MP3-SD-CD-Bluetooth-Fernbedienung-/370546850188 here are more pictures and technical details].

=== [http://uralauto.ru Ural] [http://www.cdd.ru ConceRt] ===
Russian manufacturer AAC makes an unconventional CD headunit that supports Vorbis and FLAC playback. It is being sold since end of 2005, but difficult to obtain outside Russia. An optional expansion unit provides 2.5" hard disk, USB port and AUX input.

=== [http://www.volkswagen-individual.de/ Volkswagen] Golf, Touran and others ===
:From January 2006 onwards all Golf, Golf Plus and Touran models will offer an USB port (MDI), which support USB sticks with music. Today it is available for virtually all models. Supported formats include MP3, WAV, WMA and Vorbis. Note that Ogg Vorbis support is only mentioned on the German Web site. On a related note, the iPod is supported, too.
:The new VW Polo (tested in October 2009) plays MP3, WMA, AAC (in MP4 container and bitstream-only, possible extensions are .MP4, .M4A and .AAC) ''and'' Ogg Vorbis, too.

=== <del>XcarLink or 'Audio Link" USB/Bluetooth/ipod adapter by Powermark</del> ===
for car audio
:'''Cannot play''' Vorbis.

== Car Audio - Archive (may be available second hand) ==

=== [http://www.insignia-products.com/ Insignia's] NS-C5111 CD Car deck ===
:It is being sold at [http://www.bestbuy.com/ Best Buy] as of April 2006 and will play Vorbis off of a USB drive, SD Card or from Oggs encoded onto data CDs. The Vorbis ability is undocumented. There are similar (or same) complaints as noted about the Yakumo unit below. Long TOC reads and the Random button causes track-change. The system has frozen a couple of times requiring the use of a reset button (it has one). Also problems have been experienced with nested directories, it seems to only read filenames from .ogg files, displays no ID3 info, but it constantly displays stats about the currently-playing file.

=== [http://mobile.jvc.com/product.jsp?modelId=MODL027694&pathId=54&page=1 JVC KD-G720] and [http://mobile.jvc.com/product.jsp?modelId=MODL027693&pathId=54&page=1 KD-G820] ===
:Both support Vorbis according to [http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=29933&view=findpost&p=392489 this post], however according to tommyj's review on [http://www.crutchfield.com/S-YynrlAPfgcF/cgi-bin/ProdView.asp?g=300&I=257KDG820&id=review this page] Vorbis support is limited to the USB connector and is also quite flakey. Another source suggests that JVC [http://www.jvc.ca/en/consumer/product-detail.asp?model=KD-G720 KD-G720] and KD-G820 both have undocumented, partial Vorbis support. Vorbis files can be played from a USB device attached to the USB port, but not from a CD. They do not support tags. For the vast majority of songs, q6 seems to be the highest they can reliably play. These decks are a good option for anybody looking to play Vorbis in their car because they are available at major retailers (e.g. Best Buy) and are relatively inexpensive.

=== JVC KD-G722 and KD-G721, KD-G821, KD-G827, KD-SH1000 (2005) ===
:The JVC 2005 generation of car audio can play Vorbis from USB devices. They do not recognize Vorbis tracks on other media (neither CD, nor SD-card on SH1000). Their USB slot is not powerful enough to power a real hard drive, but USB flash is no problem. The 721/722 can play Vorbis until q7 (721 and 722 only differ in color, grey or black). The 821 and 827 can play up to q5. The KD-SH1000 also plays Vorbis from USB (unknown which quality it supports).

=== <del>JVC KD-G731/831</del> ===
:These do '''not''' play Vorbis. They are the successors to the 72x/82x series, but the (undocumented) Vorbis support was '''dropped''' here.
:Official reply from JVC regarding support : ''"The following models from 2006 are the only ones to support Ogg Vorbis, KD-SH1000, KD-G821, KD-G721/722. The 2007 and planned 2008 range will not be compatible with Ogg Vorbis."''

=== Lynx CRM 2005 ===
:Low-Cost Car Radio with support to read Vorbis from CD, USB 1.1, SD and MMC. In Germany it's labeled as "Tevion CRM-2005" and was sold by Aldi-Süd. Both are Yakumo Hypersound clones.

=== [http://www.phatnoise.org/ PhatNoise's] PhatBox ===
:The PhatBox is an audio entertainment system for the car. It uses a cartridge to store the music, and it can be filled with music through a docking station for the PC. As of version 3.1 of the desktop software (Phatnoise Music Manager), Vorbis is supported out of the box. However, production was discontinued in 2007.

=== <del>VDO Dayton CD 2803, CD 2737 B</del> ===
:'''Cannot play''' Vorbis.

=== [http://www.vdodayton.com VDO Dayton] [http://www.vdodayton.com/default2_and_fz_menu=product_documents_and_dataid=523108.aspx CD 1537 X] and [http://www.vdodayton.com/default2_and_fz_menu=product_documents_and_dataid=523093.aspx CD 1737 X] ===
:These are able to play Ogg Vorbis from CD, SD/MMC and USB 1.1 devices. It can play files between 8 and 192kb/s. Up to 99 files in 99 directories (assume that means 99 in each), with names of up to 32 characters. Favorable review on [http://www.cnetfrance.fr/produits/materiels/systemes-auto-embarques/test/0,3800002254,39367497,00.htm Cnet France] (in French)
Update 4/2009: As of end of 2008 this brand has been discontinued; units are available mostly second hand. The 1537X works well with all sources and file types (tested with Audio CD, MP3/OGG from CD/SD/USB), except for the following drawbacks. It's a pity, with some improvements this could have been a decent player.
* The display (white on light blue) can not be dimmed; may be hard to read in bright light, and too bright in the night.
* Audible background noise when playing files on low volume, but doesn't stick out anymore when driving or turning up the volume.
* Directory search diplays only DOS (8.3) directory names, while file names work fine. Recommended to stick to this legacy convention from the start when naming your dirs for use with this player, else you only get 6 obfuscated characters + "~1" on the display :-(
* Only ASCII characters are displayed and converted to uppercase, everything else is shown as "*".
* SD cards up to 2 GB only. (Large enough to get lost in your directory tree. USB devices may be larger, apparently no limits to the number of files. Tested with a 8 GB keychain.)
* Random playback works only for all files on the media, not per dir/album. Random state isn't remembered on next power on.
* Operation and text display could be better in places.
Update 2/2011: Bought CD1737X from the store recently. So they are still manufacturing I assume.
* Sound quality is surely better than Opel Corca's original VDO CDR2005.
* Plays OGG like a charm, has many advanced features that I heaven't heared of before:
INT(SCAN) - plays every track (radio station) for 10 seconds (5 seconds) until one is selected to play on
REW/FFD - rewinding and fast forward support
+10/-10 - skip 10 tracks at a time (useful with big USBs)
SEARCH - searching for tracks by 3 letter pattern
VOL IN - predefine volume level at turn on
Overall satisfaction: Very high.

=== [http://www.vdodayton.com VDO Dayton] [http://www.vdodayton.com/default2_and_fz_menu=exclusive_line2.aspx Exclusive Line (2008):] [http://www.vdodayton.com/default2_and_fz_menu=tr_7327_b.aspx TR 7327 B] ===
:Advertised to have Ogg Vorbis support with bitrates from 8 up to 192 kbit/s. Manual mentions Ogg Vorbis I information tags for Album / Artist / Track name and such. So far, playback is fine and seems solid. Tag information still needs to be investigated further. Unit plays from either SD/MMC card (not SDHC!), or USB stick with max. 2GB for each. No CD drive, but spurts Bluetooth out of the box at a reasonable price. User Manual and data sheet are available as PDF for download from the product page. Included (but not mentioned anywhere) was a cable for iPod to be connected to a rear AUX input, yet support said it is Audio only, i.e. no iPod operation driven by the head unit.

=== <del> [http://www.yakumo.com/produkte/index.php?pid=1&ag=Autoradio Yakumo's] Hypersound Car </del>===

'''Company doesn't exist anymore'''

:This in-dash car CD player supports Vorbis, MP3, and WMA playback from CD, USB stick or MMC/SD card. Vorbis support is not obvious but are clearly specified in the Technical Specifications page of the user manual, but has been verified to work with both UK and German versions. Reservations [http://www.tomergabel.com/TheQuestForTheHolyErSound.aspx have been made] regarding the product's quality, in particular stability and performance. (There was also a Yakumo Support Forum Discussion, but Yakumo seem to have taken their forums offline as of March 2007. Partial archive [http://www.moteprime.org/article.php?id=30 here].)It supports Vorbis files on USB, MMC/SD and CD. However, as of early 2006 its firmware is notoriously flaky, no firmware update is available, and it also has poor tuner sensitivity. This is also supplied in unbranded form at various retailers, but it does have a distinctive look. [http://www.yakumo.de/produkte/index.php?pid=1&ag=Autoradio <del> Yakumo Car Entertainment </del>]. [http://www.yakumo.com/datafiles/produkte/manuals/man_1037991_38_2_yakumo_hypersound_car_eazy.pdf <del> Online manual </del>]. See also Acoustic Solutions ICS-160.

''Note: Some of this information was moved from the Mobile Players page, so there may be some duplication.''

== Media Storage ==

=== [http://www.gennetworks.com/ GenNetwork's] GenMedia DivXStorage ===
:This is an external harddrive as a video storage to connect to TV sets. It comes in various versions and storage sizes. It comes with USB 2.0 and a remote control. HDTV resolution, 5.1 sound and the following file formats are supported: MPEG-4/DVD/VCD/SVCD/AudioCD/JPEG/MP3. For the [http://www.gennetworks.com/pro_genmedia02.htm 3,5"] and deck version Vorbis format is mentioned.

=== [http://www.numark.com/ Numark's] HDX, HDMix ===
:These are DJ media players with a 80GB HD on-board and a CD drive. They support Hard Drive Playback of MP3, WMA, WAV, Vorbis, and FLAC (lossless) formats. See [http://www.numark.com/ homepage] for more.

=== [http://www.cirago.com/ Cirago's] CMC1000 and CMC500 ===
:These are Wireless-capable DVR or maybe just DVP devices.

[[Category:Vorbis]]

Talk:Games that use Vorbis

2012-12-29T20:36:23Z

Martin.leese: /* SCS/SCSD */ Added attribution

* I'm a beta tester (for Savage) has this been added yet? I still see quite a few .wav's (trelane)
* Yes, those are sound effects. Vorbis is only used for music, because you wouldn't want to burden the CPU with decoding 24 oggs simultaneously (slothy).
* Of course you could decode the sound samples ahead of time and avoid the decode on the fly silliness. (xcaliber)
*At the expense of load time slowness if you do it then, or install time slowness if you do it during the install. If you do it during the install, you've only saved yourself space on the CD, which you can probably do in other ways as well. Plus most games don't keep all the sounds loaded in memory, so decompressing them to memory isn't a good thing, it's a RAM hog. This is why nobody should use any compressed codecs for sound effects in games. (slothy)
* Doesn't the PC version of GTA San Andreas Use Vorbis?
* It seems like Black and White 2 by Lionhead uses Ogg Vorbis.

Are there notability guidelines? --[[User:Damian Yerrick|Damian Yerrick]] 23:36, 21 October 2006 (PDT)

Many of these links go to web pages that are only accessible with Adobe's proprietary Flash Player installed. Using web pages that support open formats might be better, than the official pages. Additionally, using a more encyclopedic resource might keep the links alive longer than the shockingly short support period for these software titles. --[[User:Matthewcraig|Matthew Craig]] 19:21, 25 August 2008 (EDT)

Vorbis doesn't seem to be compatible with Creative ALchemy or Asus Xonar GX mode (EAX 2.0 compability mode.) It causes frequent lockup with Fallout 3 (uses mix of MP3 and Ogg audio) and Grand Theft Auto: San Andreas (no audio with GX on) to just name two.

GX (EAX 2.0, DS3D compatibility on Vista) works fine with games using MP3, wav or other audio formats, as far as I know.

== Grand Theft Auto: Vice City . Everything in MP3. No Vorbis. Double checked ==

Yeah, really I've checked it right now. There is no OGG Vorbis support, and the rockstar site mentions no support for OGG Vorbis either, so vice city will have to go from the list. [[User:Gnetter|Gnetter]] 13:31, 15 January 2010 (UTC)

== SCS/SCSD ==

I found that Simcity Societies (and the expansion) uses .ogg for it's audio.
'''===}>DISCLAIMER: I DO [[NOT]] OWN ANY PART OF SIMCITY SOCIETIES OR SIMCITY SOCIETIES DESTINATIONS, UNLESS BUYING THE GAME AND/OR IT'S SOUNDTRACK ON iTUNES COUNTS (TO CLEAR UP ANY CONFUSION, I DID NOT BUY THE GAME ITSELF ON iTUNES). ALSO, I DO [[NOT]] OWN ANY PART OF iTUNES, UNLESS BUYING MUSIC ON IT COUNTS.<{===''' [[User:Creeperchair|Creeperchair]] 20:56, 28 December 2012 (UST)

User talk:DOS386

2012-12-26T18:27:01Z

Martin.leese: /* Handling SPAM */ new section

For the last time, it is not "OGG". Please stop that. It causes a lot of problems. Please don't stop contributing, however. We appreciate your help.--[[User:Saoshyant|Ivo]] 17:41, 7 August 2007 (PDT)

== not OGG ==

> it '''is not "OGG".''' Please stop that. It causes a lot of problems.

What then ? ;-) [[User:DOS386|DOS386]] 14:46, 19 October 2007 (PDT)

:Ogg is not an acronym and should not be treated as such. When talking about Ogg files, as in content inside the container, you should refer to it as either Ogg Video, Ogg Audio, or Ogg Application. When you see someone saying "OGG", they usually mean Vorbis, so you see, you should avoid using those terms because it reveals ignorance for Ogg is not Vorbis, and Vorbis is not Ogg, although Vorbis does show up inside Ogg frequently.--[[User:Saoshyant|Ivo]] 06:49, 20 October 2007 (PDT)

== Handling SPAM ==

Please don't add <nowiki>{{Delete}}</nowiki> or move newly created SPAM pages. This just makes them more difficult to process (by creating <nowiki>#REDIRECT</nowiki>s). There are lots of editors patrolling for newly created SPAM, so there is no need to highlight such pages. (If you spot ''old'' SPAM pages then that is a different matter.) Many thanks, [[User:Martin.leese|Martin Leese]] 10:27, 26 December 2012 (PST)

FLACDecoders

2012-10-29T20:14:36Z

Martin.leese: Added FLAC.js

* [http://flac.sourceforge.net/ xiph]
* [http://ffmpeg.org ffmpeg]
* [http://labs.official.fm/articles/2012/06/15/flac-and-aurora/ FLAC.js], a pure JavaScript FLAC decoder

VorbisComment

2012-10-12T18:23:43Z

Martin.leese: /* Proposed field names */ Removed Chapter Extension as it has its own section further down

VorbisComment is a base-level [[Metadata]] format initially created for use with Ogg [[Vorbis]]. It has since been adopted in the specifications of
[[Ogg]] encapsulations for other Xiph.Org codecs including [[Theora]], [[Speex]] and [[FLAC]].

The use case for VorbisComment is given as:
<blockquote>
... 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.[http://xiph.org/vorbis/doc/v-comment.html]
</blockquote>

VorbisComments are typically used to provide basic information like the title and copyright holder of a work.
As such the scope is similar to that of ID3 tags used with MP3 files.
VorbisComment is widely supported on [[VorbisHardware|portable Ogg Vorbis players]] as well as streaming, editing and playback software.

Although the syntax of VorbisComment is well-specified, various conventions exist for the field names in use.
The goal for this page is to codify best practices and collect proposals for standardization of VorbisComment field names.

VorbisComments are typically encoded as the second packet in a codec stream. When VorbisComments are included in the first (ie. Theora) stream of an Ogg Theora file, they are assumed to cover all streams in the multiplexed group. [http://lists.xiph.org/pipermail/vorbis-dev/2008-December/019676.html]

VorbisComment is the simplest and most widely-supported mechanism for storing metadata with Xiph.Org codecs. For other existing and proposed mechanisms, see [[Metadata]].

== Recommended field names ==

The current [http://xiph.org/vorbis/doc/v-comment.html VorbisComment recommendation] contains a recommended set
of field names for comments.

== Proposed field names ==

Some proposals for extra field names:

* [http://age.hobba.nl/audio/mirroredpages/ogg-tagging.html Ogg Vorbis Comment Field Recommendations]
* [http://gophernet.org/articles/vorbiscomment/ Proposals for extending Ogg Vorbis comments]
* [[Field names]]

Comments are intended to be free-form, but for the purposes of interoperability, it is helpful to define tag sets for particular applications, and provide some guidelines for machine parsing. Note that some field names have to be non-free-form to achieve machine parsing.

=== Cover art ===

==== METADATA_BLOCK_PICTURE ====
The [http://flac.sourceforge.net/format.html#metadata_block_picture binary FLAC picture structure] is base64 encoded and placed within a VorbisComment with the tag name "METADATA_BLOCK_PICTURE". This is the preferred and recommended way of embedding cover art within VorbisComments. It has the following benefits:

* Easy to use for developers since the identical (or similar) structure is also used by FLAC and MP3.
* The cover art can either be linked or embedded within the stream.
* Common picture file formats are supported (jpg and png).
* A description may be included and the picture type (front cover, back cover...) and image mime type are provided.
* Base64 encoded data is invariant under UTF-8 and a valid UTF-8 string, so obeys the rules for comment data.

Implementations interpreting or writing picture blocks should note the following details:

===== General encoding/decoding =====
* Failure to decode a picture block should not prevent playback of the file (failure to deal with the particularly large packet required by the comment header is a separate problem with the player implementation).
* Base64 encoding is used as in section 4 of [http://www.faqs.org/rfcs/rfc4648.html RFC4648]. We note that line feeds are not allowed and padding characters ('=') are required.
* Applications adding picture blocks should inform users that some applications or hardware may not support them and should provide a method to remove the blocks (this is expected to be trivial for applications capable of adding them).

===== Block handling =====
* The unencoded format is that of the [http://flac.sourceforge.net/format.html#metadata_block_picture FLAC picture block]. The fields are stored in big endian order as in FLAC, picture data is stored according to the relevant standard.
* Picture data should be stored in PNG or JPEG formats or linked separately. It is recommended readers support both PNG and JPEG
* Allowed values for the MIME string are "image/", "image/png", "image/jpeg" and "-->" (the link indicator) and "" (length 0). An empty MIME string indicates type "image/"
* Fields present in the ID3V2.4.0 [http://www.id3.org/id3v2.4.0-frames#line-1085 Attached Picture Frame] (APIC Frame) take the same interpretation as in the ID3V2.4.0 format with the following exceptions (following the FLAC format):
** The description field is UTF-8 (encoded without ID3V2's initial 'encoding byte')
** String fields are not null terminated: their preceding length fields are used instead.

===== Linked images =====
Support for linked images is optional for applications handling picture blocks. When a linked picture is indicated the following rules are observed:
* The picture data is a complete URL indicating the picture to be used, relative URLs are allowed (note relative URLs do not start with a protocol specifier and are retrieved with the same protocol as the file being processed).
* Links are ISO-8859-1 encoded
* Applications MAY retrieve linked images via the file:// protocol.
* Applications MUST obtain user approval if they wish to retrieve images via remote protocols.
* Link targets may become unavailable: applications supporting linked images SHOULD recover gracefully from this and MAY report the absence to the user.
* The type of the linked file is not restricted to JPEG and JFIF and applications MAY support other formats
* If the application does not support linked images, the target is unavailable, not permitted or an unknown format the picture block should be skipped.
* Applications may make links available to users, this is of particular use when links are unsupported or of unsupported type

===== Image dimension fields =====
* The height, width, colour depth and 'number of colours' fields are for purely informational purposes. Applications MUST NOT use them for decoding purposes, but MAY display them to the user and MAY use them to make a decision whether to skip the block (for example if selecting the most appropriate among multiple blocks).
* Applications writing picture blocks MUST set these fields correctly OR set them all to zero.

===== Multiple blocks =====
* Multiple image blocks MAY be included as separate METADATA_BLOCK_PICTURE comments.
* There may only be one each of picture type (APIC type) 1 and 2 in a Vorbis stream.
* Block order is significant for some types and applications should preserve the comment order when reading or writing VorbisComment headers. The block order may be used to determine the order pictures are presented to the user.

===== Playback tests =====
Embedding a picture into the file might break playback of existing players (especially hardware players, software players could be updated easily). A workaround would be to link the picture within the tag. Furthermore users should become informed in some way that embedding a picture COULD cause problems (as stated above).

In order to test if there are playback problems, there are test files available [http://www.audioranger.com/coverart_mk.ogg here] and [http://www.audioranger.com/coverart_im.ogg here]. You're invited to download one of these test files (or both), test playback on your software and hardware players, and report the results here on the wiki.

'''Tested software players'''
* Audacious 1.5.1: no problem
* foobar2000: no problems
* Gnome: built-in preview playback: no problem
* MediaMonkey: no problems
* Media Player Classic (unicode build) 6.4.9.1: no problem
* RoarAudio: no problems (server and client side)
* Rythmbox 0.11.6: no problem
* Totem 2.24.3: no problem
* VLC 0.9.4/0.9.6: doesn't play
** Patch send to VLC to fix this - should get in 1.0.0
* WinAmp: no problems
* Windows Media Player 11: no problem
* XMPlay 3.4.2: no problem
* Nero ShowTime: no problem
* Songbird 1.8.0: no problem, able to show and edit embedded pictures

'''Tested hardware players'''
* Logitech Squeezebox: Supported as of January 2009 (server version 7.3.3)
* Sandisk Sansa Fuze (Firmware 01.01.22): Hangs up when trying to playback the demo file - had to reset the player
** Note: The "Fuze" can play ogg vorbis files which have embedded pictures from "Easytag"
* Cowon iAudio U3 (Firmware 1.29, 4 GB): works
* Cowon D2: no problem (latest Firmware: 2.59, 8GB Version)
* iRiver E100: no problem (latest Firmware: 1.16 G_U, 8GB Version)
* iRiver T20: doesn't play (firmware: 1.71, 1GB)
* Samsung YP-R1: no problem (latest Firmware: 3.07, 16GB Version)

'''Tested tag editors'''
* Easytag 2.1.6: can open the file to edit the normal tag fields
* MP3Tag 2.42e: can open the file to edit the normal tag fields
* MP3Tag 2.47b: is able to show and edit embedded pictures

'''Tested other software'''
* Total Recorder: capable to work with artwork according to the specification.

==== Unofficial COVERART field (deprecated) ====
There also exists an unofficial, not well supported comment field named "COVERART". It includes a base64-encoded string of the binary picture data (usually a JPEG file, but this could be a different file format too). The disadvantages are that
* no additional information like a description about the cover art or its type (front cover, back cover etc.) is provided,
* the cover art can't be linked
* the base64 string is displayed within many tag editors as plain text because of their missing support for this "COVERART" field
* it may breaks the playback on hardware players because of a large VorbisComment header
The unofficial "COVERART" field is supported for example by such software as AudioShell (http://www.softpointer.com/AudioShell.htm) - read/write, and Total Recorder (http://www.totalrecorder.com/)- only read.

===== Conversion to METADATA_BLOCK_PICTURE =====
Old "COVERART" tags should be converted to the new METADATA_BLOCK_PICTURE tag (see above for its specification). This conversion is straightforward and is suggested to be done the following way:

* Decode the COVERART tag. A program MAY check the signature of the embedded picture in order to determine whether it is an allowed type. Lossless conversion from disallowed types to allowed types MAY be carried out.
* Fill out the FLAC block with the binary picture data. If the MIME type of the picture is unknown or can't be determined, the MIME type "image/" MAY be used instead. Supplying image dimensions, color depth etc. is optional (see specification above).
* In the absence of other information the picture type 'Other' should be used. Applications may want to allow users to select a default type or specify the type to use.
* Encode the new picture block, remove the COVERART tag from the comments and add the METADATA_BLOCK_PICTURE entry.
* If multiple tags are being converted the order of the METADATA_BLOCK_PICTURE tags should be the same as that of the COVERART tags they are replacing.

=== Chapter Extension ===

These are used to include navigation points, for example:
<pre>
CHAPTER001=00:00:00.000
CHAPTER001NAME=Chapter 1
CHAPTER001URL=http://...
</pre>

See the [[Chapter Extension]] page for more details.

=== Date and time ===

The goal is to specify '''one''' standard format for describing date and/or time.

==== ISO proposal ====
The date format for any field describing a date must follow the ISO 8601 standard: YYYY-MM-DD, shortened to just YYYY-MM or simply YYYY.

We have been recommending this usage with the DATE tag for some time. It is proposed that the spec be amended to include this information for machinability.

The time format for any field '''except''' track duration must be specified with leading T and ending with a time zone. Schemas with and without dates:
<pre>
YYYY-MM-DDTHH:MM:SS+TS
</pre>
<pre>
THH:MM+TZ
</pre>

=== ENCODER ===

The goal is to attribute encoder software. This value can be used in the future to determine which files can be improved by being re encoded with a newer version.

:'''Comment''': What is lacking from the vendor string present in the spec from the start? All libvorbis and encoder tunings I'm aware of have recorded the encoder version here.

Rationale for not using the vendor string:
* The vendor string is usually used to store the name and version of the underlying codec library
* The idea of ENCODER is to store the name of the user-visible application, for example <tt>ffmpeg2theora</tt>.
* It can be useful for debugging to store the name and version of the calling application.
* The libvorbis API does not let applications override the vendor string.

==== Proposal: Inclusion of URL in ENCODER value ====
The encoder field name must be a unique URL providing both encoder software name and version. If no unique URL address is available were both name and version is available; then the version number can be specified by separating with a space character. For example:

<nowiki>ENCODER=http://flac.sourceforge.net/ 1.2.1</nowiki>

* Note that ffmpeg2theora uses ENCODER, but does not include a url. ''Added by Rillian on September 17, 2007''

==== Proposal: ENCODED_BY ====

I've also seen ENCODED_BY. ''Added by Rillian on September 17, 2007''
: ENCODED_BY is usually the person who did the encoding. This should not be part of the recommendation due to legal problems around deliberate and accidental distribution to third parties. Basically the name of the encoder should not be included to protect encoders from their own egos and possible legal prosecution. ''Added by Aleksandersen on September 20, 2007''

=== Improving license data ===

The goal is to provide a method for proclaiming license and copyright information (basically clarifying ‘distribution rights (if any) and ownership’).

The [http://xiph.org/vorbis/doc/v-comment.html specification document] describes LICENSE and COPYRIGHT fields. But is not clear enough about whether these should be machine-readable.

We should consider working together with Creative Commons to have complementary and interlinked information on the Creative Commons and Xiph wikis. Refer to the [http://wiki.creativecommons.org/Ogg Ogg page] in the Creative Commons wiki.

==== New RIGHTS field name proposal ====
One proposal is to replace the COPYRIGHT and LICENSE field names with RIGHTS. RIGHTS must be a human-readable copyright statement. Basic example:

<nowiki>RIGHTS=Copyright © Recording Company Inc. All distribution rights reserved.</nowiki>

But this is not machine-readable. Adding two complementary field names should do the trick: RIGHTS-DATE, describing the date of copyright; and RIGHTS-URI, providing a method for linking to a license. Software agents can assume that multiple songs uses the sameURIs, such as in the case for Creative Commons. Full example:

<nowiki>RIGHTS=Copyright © 2019 Recording Company Inc. All distribution rights reserved.</nowiki> 
<nowiki>RIGHTS-DATE=2019-04</nowiki> 
<nowiki>RIGHTS-URI=http://somewhere.com/license.xhtml</nowiki>

Software such as for multimedia management and playback are encouraged to display the RIGHTS statement as a linked phrase using RIGHTS-URI.

RIGHTS-DATE does not need to be displayed as it is required in the human readable version by international copyright agreements. RIGHTS-DATE can be used to determine when a copyrighted work falls under the public domain and related matters. (''The Beatles''' copyright on their original studio recordings (not the remixes) are soon expiering. So mechanisms such as the RIGHTS-DATE are indeed required in music management and filesharing software!)

To remain machine-readable it would be required to have at most one instance of each RIGHTS field name. All fields would of course remain optional.

The ''Dublin Core Metadata Initiative'' recommends the use of ‘rights’ to describe license and copyright matters. The web feed format Atom 1.0 has implemented a rights element in their specification.

:'''Comment''': The triplet RIGHTS, RIGHTS-DATE, RIGHTS-URI is an example of structured metadata. VorbisComments are inherently unstructured, and this should be respected. Structured metadata belongs in a different stream, such as XML (using [[Metadata#XMLEmbedding|XMLEmbedding]]).

==== Improving existing fields proposal ====
Similar to the DATE tag above, we have generally recommended that a URL uniquely identifying the license be included in the LICENSE field to allow machine identification of the license. This is in agreement with the proposal in the Creative Commons wiki. Since the COPYRIGHT field is a human-readable statement of the copyright, like the proposed RIGHTS tag above, some people include a license url there. Therefore if a url can't be found in a LICENSE tag if any, applications should use one from the COPYRIGHT tag, if any. Contact information for verification, attribution, relicensing, etc. can be obtained from the COPYRIGHT field, but Creative Commons also recommend a separate CONTACT tag for this information. This is reasonable, so we propose it be included.

=== Geo Location fields ===

The existing LOCATION field is meant to carry a human readable location for the recording/creation of the media file.

Having geographical coordinates according to [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84] can be useful as well, especially in a form that can be machine parsed. The agreed format is similar to this [http://en.wikipedia.org/wiki/Geo_(microformat) geo microformat]:

GEO_LOCATION= ''latitude'' ; ''longitude'' [; ''elevation'' ]

where each value is a fixed point decimal number formatted in the C locale with a period (.) for the radix. Values are separated with a ';' and white space is not significant. The elevation is optional.

''latitude'' is the geo latitude location of where the media has been recorded or produced in decimal degrees according to WGS84 (zero at the equator, negative values for southern latitudes) (C double).

''longitude'' is the geo longitude location of where the media has been recorded or produced in decimal degrees according to WGS84 (zero at the prime meridian in Greenwich/UK, negative values for western longitudes). (C double).

''elevation'' is the geo elevation of where the media has been recorded or produced in meters according to WGS84 (zero is average sea level) (C double).

=== Replay Gain ===

The REPLAYGAIN_* fields implement the Replay Gain proposal for storing a track relative volume adjustment, which can be used to "fix" quiet or loud sounding Vorbis or FLAC streams. The set of tags is intended to be machine parsed, and has the following form:
<pre>
REPLAYGAIN_TRACK_GAIN=-7.03 dB
REPLAYGAIN_TRACK_PEAK=1.21822226
REPLAYGAIN_ALBUM_GAIN=-6.37 dB
REPLAYGAIN_ALBUM_PEAK=1.21822226
</pre>

See http://www.replaygain.org/ for detailed information about Replay Gain and how the different values are calculated.

=== Tantalos resource ID ===
Tantalos is a protocol to auto locate and access content in a network scope (normally 'LAN' but can also be bigger like 'company network'). It uses UUIDs to identify resources. There are two groups of those UUIDs: IDs generated using the meta data of the track and IDs generated in some other way (for example random IDs, see UUID specs). The later group may need to be passed with the track. The VCLT Playlist format (see below) uses 'HASH={UUID}id...' with hex-dash format for this (HASH={UUID}e278173d-4d6d-4c66-95ec-4ec85eedc7d1).
--[[User:Ph3-der-loewe|Ph3-der-loewe]] 02:05, 13 December 2011 (PST)

== Other (non-proposed field names) ==
=== VCLT playlist format ===
The VCLT playlist format uses some ''keys'' which look like VorbisComments but they aren't nor they are proposed to become (expect for HASH). This includes the keys STREAMURL, FILENAME, FILEURL, LENGTH, HASH (see above for this one), SIGNALINFO, AUDIOINFO and OFFSET. You can find more infos about those at [https://bts.keep-cool.org/wiki/Specs/VCLT https://bts.keep-cool.org/wiki/Specs/VCLT].

== Implementations ==

* [http://sbooth.org/importers/ OggImporter] – imports Ogg Vorbis and Ogg FLAC files to Spotlight.
* vorbiscomment – a commandline tool, part of [[VorbisTools]].
* [http://www.xiph.org/oggz/ oggz-comment] – a commandline tool, part of [[Oggz]] tool. It can add comments to multitrack and video files.

VorbisComment

2012-10-12T18:07:44Z

Martin.leese: /* Chapter Extension */ Updated example to match simpler format

VorbisComment is a base-level [[Metadata]] format initially created for use with Ogg [[Vorbis]]. It has since been adopted in the specifications of
[[Ogg]] encapsulations for other Xiph.Org codecs including [[Theora]], [[Speex]] and [[FLAC]].

The use case for VorbisComment is given as:
<blockquote>
... 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.[http://xiph.org/vorbis/doc/v-comment.html]
</blockquote>

VorbisComments are typically used to provide basic information like the title and copyright holder of a work.
As such the scope is similar to that of ID3 tags used with MP3 files.
VorbisComment is widely supported on [[VorbisHardware|portable Ogg Vorbis players]] as well as streaming, editing and playback software.

Although the syntax of VorbisComment is well-specified, various conventions exist for the field names in use.
The goal for this page is to codify best practices and collect proposals for standardization of VorbisComment field names.

VorbisComments are typically encoded as the second packet in a codec stream. When VorbisComments are included in the first (ie. Theora) stream of an Ogg Theora file, they are assumed to cover all streams in the multiplexed group. [http://lists.xiph.org/pipermail/vorbis-dev/2008-December/019676.html]

VorbisComment is the simplest and most widely-supported mechanism for storing metadata with Xiph.Org codecs. For other existing and proposed mechanisms, see [[Metadata]].

== Recommended field names ==

The current [http://xiph.org/vorbis/doc/v-comment.html VorbisComment recommendation] contains a recommended set
of field names for comments.

== Proposed field names ==

Some proposals for extra field names:

* [http://age.hobba.nl/audio/mirroredpages/ogg-tagging.html Ogg Vorbis Comment Field Recommendations]
* [http://gophernet.org/articles/vorbiscomment/ Proposals for extending Ogg Vorbis comments]
* [[Field names]]
* [[Chapter Extension]]

Comments are intended to be free-form, but for the purposes of interoperability, it is helpful to define tag sets for particular applications, and provide some guidelines for machine parsing. Note that some field names have to be non-free-form to achieve machine parsing.

=== Cover art ===

==== METADATA_BLOCK_PICTURE ====
The [http://flac.sourceforge.net/format.html#metadata_block_picture binary FLAC picture structure] is base64 encoded and placed within a VorbisComment with the tag name "METADATA_BLOCK_PICTURE". This is the preferred and recommended way of embedding cover art within VorbisComments. It has the following benefits:

* Easy to use for developers since the identical (or similar) structure is also used by FLAC and MP3.
* The cover art can either be linked or embedded within the stream.
* Common picture file formats are supported (jpg and png).
* A description may be included and the picture type (front cover, back cover...) and image mime type are provided.
* Base64 encoded data is invariant under UTF-8 and a valid UTF-8 string, so obeys the rules for comment data.

Implementations interpreting or writing picture blocks should note the following details:

===== General encoding/decoding =====
* Failure to decode a picture block should not prevent playback of the file (failure to deal with the particularly large packet required by the comment header is a separate problem with the player implementation).
* Base64 encoding is used as in section 4 of [http://www.faqs.org/rfcs/rfc4648.html RFC4648]. We note that line feeds are not allowed and padding characters ('=') are required.
* Applications adding picture blocks should inform users that some applications or hardware may not support them and should provide a method to remove the blocks (this is expected to be trivial for applications capable of adding them).

===== Block handling =====
* The unencoded format is that of the [http://flac.sourceforge.net/format.html#metadata_block_picture FLAC picture block]. The fields are stored in big endian order as in FLAC, picture data is stored according to the relevant standard.
* Picture data should be stored in PNG or JPEG formats or linked separately. It is recommended readers support both PNG and JPEG
* Allowed values for the MIME string are "image/", "image/png", "image/jpeg" and "-->" (the link indicator) and "" (length 0). An empty MIME string indicates type "image/"
* Fields present in the ID3V2.4.0 [http://www.id3.org/id3v2.4.0-frames#line-1085 Attached Picture Frame] (APIC Frame) take the same interpretation as in the ID3V2.4.0 format with the following exceptions (following the FLAC format):
** The description field is UTF-8 (encoded without ID3V2's initial 'encoding byte')
** String fields are not null terminated: their preceding length fields are used instead.

===== Linked images =====
Support for linked images is optional for applications handling picture blocks. When a linked picture is indicated the following rules are observed:
* The picture data is a complete URL indicating the picture to be used, relative URLs are allowed (note relative URLs do not start with a protocol specifier and are retrieved with the same protocol as the file being processed).
* Links are ISO-8859-1 encoded
* Applications MAY retrieve linked images via the file:// protocol.
* Applications MUST obtain user approval if they wish to retrieve images via remote protocols.
* Link targets may become unavailable: applications supporting linked images SHOULD recover gracefully from this and MAY report the absence to the user.
* The type of the linked file is not restricted to JPEG and JFIF and applications MAY support other formats
* If the application does not support linked images, the target is unavailable, not permitted or an unknown format the picture block should be skipped.
* Applications may make links available to users, this is of particular use when links are unsupported or of unsupported type

===== Image dimension fields =====
* The height, width, colour depth and 'number of colours' fields are for purely informational purposes. Applications MUST NOT use them for decoding purposes, but MAY display them to the user and MAY use them to make a decision whether to skip the block (for example if selecting the most appropriate among multiple blocks).
* Applications writing picture blocks MUST set these fields correctly OR set them all to zero.

===== Multiple blocks =====
* Multiple image blocks MAY be included as separate METADATA_BLOCK_PICTURE comments.
* There may only be one each of picture type (APIC type) 1 and 2 in a Vorbis stream.
* Block order is significant for some types and applications should preserve the comment order when reading or writing VorbisComment headers. The block order may be used to determine the order pictures are presented to the user.

===== Playback tests =====
Embedding a picture into the file might break playback of existing players (especially hardware players, software players could be updated easily). A workaround would be to link the picture within the tag. Furthermore users should become informed in some way that embedding a picture COULD cause problems (as stated above).

In order to test if there are playback problems, there are test files available [http://www.audioranger.com/coverart_mk.ogg here] and [http://www.audioranger.com/coverart_im.ogg here]. You're invited to download one of these test files (or both), test playback on your software and hardware players, and report the results here on the wiki.

'''Tested software players'''
* Audacious 1.5.1: no problem
* foobar2000: no problems
* Gnome: built-in preview playback: no problem
* MediaMonkey: no problems
* Media Player Classic (unicode build) 6.4.9.1: no problem
* RoarAudio: no problems (server and client side)
* Rythmbox 0.11.6: no problem
* Totem 2.24.3: no problem
* VLC 0.9.4/0.9.6: doesn't play
** Patch send to VLC to fix this - should get in 1.0.0
* WinAmp: no problems
* Windows Media Player 11: no problem
* XMPlay 3.4.2: no problem
* Nero ShowTime: no problem
* Songbird 1.8.0: no problem, able to show and edit embedded pictures

'''Tested hardware players'''
* Logitech Squeezebox: Supported as of January 2009 (server version 7.3.3)
* Sandisk Sansa Fuze (Firmware 01.01.22): Hangs up when trying to playback the demo file - had to reset the player
** Note: The "Fuze" can play ogg vorbis files which have embedded pictures from "Easytag"
* Cowon iAudio U3 (Firmware 1.29, 4 GB): works
* Cowon D2: no problem (latest Firmware: 2.59, 8GB Version)
* iRiver E100: no problem (latest Firmware: 1.16 G_U, 8GB Version)
* iRiver T20: doesn't play (firmware: 1.71, 1GB)
* Samsung YP-R1: no problem (latest Firmware: 3.07, 16GB Version)

'''Tested tag editors'''
* Easytag 2.1.6: can open the file to edit the normal tag fields
* MP3Tag 2.42e: can open the file to edit the normal tag fields
* MP3Tag 2.47b: is able to show and edit embedded pictures

'''Tested other software'''
* Total Recorder: capable to work with artwork according to the specification.

==== Unofficial COVERART field (deprecated) ====
There also exists an unofficial, not well supported comment field named "COVERART". It includes a base64-encoded string of the binary picture data (usually a JPEG file, but this could be a different file format too). The disadvantages are that
* no additional information like a description about the cover art or its type (front cover, back cover etc.) is provided,
* the cover art can't be linked
* the base64 string is displayed within many tag editors as plain text because of their missing support for this "COVERART" field
* it may breaks the playback on hardware players because of a large VorbisComment header
The unofficial "COVERART" field is supported for example by such software as AudioShell (http://www.softpointer.com/AudioShell.htm) - read/write, and Total Recorder (http://www.totalrecorder.com/)- only read.

===== Conversion to METADATA_BLOCK_PICTURE =====
Old "COVERART" tags should be converted to the new METADATA_BLOCK_PICTURE tag (see above for its specification). This conversion is straightforward and is suggested to be done the following way:

* Decode the COVERART tag. A program MAY check the signature of the embedded picture in order to determine whether it is an allowed type. Lossless conversion from disallowed types to allowed types MAY be carried out.
* Fill out the FLAC block with the binary picture data. If the MIME type of the picture is unknown or can't be determined, the MIME type "image/" MAY be used instead. Supplying image dimensions, color depth etc. is optional (see specification above).
* In the absence of other information the picture type 'Other' should be used. Applications may want to allow users to select a default type or specify the type to use.
* Encode the new picture block, remove the COVERART tag from the comments and add the METADATA_BLOCK_PICTURE entry.
* If multiple tags are being converted the order of the METADATA_BLOCK_PICTURE tags should be the same as that of the COVERART tags they are replacing.

=== Chapter Extension ===

These are used to include navigation points, for example:
<pre>
CHAPTER001=00:00:00.000
CHAPTER001NAME=Chapter 1
CHAPTER001URL=http://...
</pre>

See the [[Chapter Extension]] page for more details.

=== Date and time ===

The goal is to specify '''one''' standard format for describing date and/or time.

==== ISO proposal ====
The date format for any field describing a date must follow the ISO 8601 standard: YYYY-MM-DD, shortened to just YYYY-MM or simply YYYY.

We have been recommending this usage with the DATE tag for some time. It is proposed that the spec be amended to include this information for machinability.

The time format for any field '''except''' track duration must be specified with leading T and ending with a time zone. Schemas with and without dates:
<pre>
YYYY-MM-DDTHH:MM:SS+TS
</pre>
<pre>
THH:MM+TZ
</pre>

=== ENCODER ===

The goal is to attribute encoder software. This value can be used in the future to determine which files can be improved by being re encoded with a newer version.

:'''Comment''': What is lacking from the vendor string present in the spec from the start? All libvorbis and encoder tunings I'm aware of have recorded the encoder version here.

Rationale for not using the vendor string:
* The vendor string is usually used to store the name and version of the underlying codec library
* The idea of ENCODER is to store the name of the user-visible application, for example <tt>ffmpeg2theora</tt>.
* It can be useful for debugging to store the name and version of the calling application.
* The libvorbis API does not let applications override the vendor string.

==== Proposal: Inclusion of URL in ENCODER value ====
The encoder field name must be a unique URL providing both encoder software name and version. If no unique URL address is available were both name and version is available; then the version number can be specified by separating with a space character. For example:

<nowiki>ENCODER=http://flac.sourceforge.net/ 1.2.1</nowiki>

* Note that ffmpeg2theora uses ENCODER, but does not include a url. ''Added by Rillian on September 17, 2007''

==== Proposal: ENCODED_BY ====

I've also seen ENCODED_BY. ''Added by Rillian on September 17, 2007''
: ENCODED_BY is usually the person who did the encoding. This should not be part of the recommendation due to legal problems around deliberate and accidental distribution to third parties. Basically the name of the encoder should not be included to protect encoders from their own egos and possible legal prosecution. ''Added by Aleksandersen on September 20, 2007''

=== Improving license data ===

The goal is to provide a method for proclaiming license and copyright information (basically clarifying ‘distribution rights (if any) and ownership’).

The [http://xiph.org/vorbis/doc/v-comment.html specification document] describes LICENSE and COPYRIGHT fields. But is not clear enough about whether these should be machine-readable.

We should consider working together with Creative Commons to have complementary and interlinked information on the Creative Commons and Xiph wikis. Refer to the [http://wiki.creativecommons.org/Ogg Ogg page] in the Creative Commons wiki.

==== New RIGHTS field name proposal ====
One proposal is to replace the COPYRIGHT and LICENSE field names with RIGHTS. RIGHTS must be a human-readable copyright statement. Basic example:

<nowiki>RIGHTS=Copyright © Recording Company Inc. All distribution rights reserved.</nowiki>

But this is not machine-readable. Adding two complementary field names should do the trick: RIGHTS-DATE, describing the date of copyright; and RIGHTS-URI, providing a method for linking to a license. Software agents can assume that multiple songs uses the sameURIs, such as in the case for Creative Commons. Full example:

<nowiki>RIGHTS=Copyright © 2019 Recording Company Inc. All distribution rights reserved.</nowiki> 
<nowiki>RIGHTS-DATE=2019-04</nowiki> 
<nowiki>RIGHTS-URI=http://somewhere.com/license.xhtml</nowiki>

Software such as for multimedia management and playback are encouraged to display the RIGHTS statement as a linked phrase using RIGHTS-URI.

RIGHTS-DATE does not need to be displayed as it is required in the human readable version by international copyright agreements. RIGHTS-DATE can be used to determine when a copyrighted work falls under the public domain and related matters. (''The Beatles''' copyright on their original studio recordings (not the remixes) are soon expiering. So mechanisms such as the RIGHTS-DATE are indeed required in music management and filesharing software!)

To remain machine-readable it would be required to have at most one instance of each RIGHTS field name. All fields would of course remain optional.

The ''Dublin Core Metadata Initiative'' recommends the use of ‘rights’ to describe license and copyright matters. The web feed format Atom 1.0 has implemented a rights element in their specification.

:'''Comment''': The triplet RIGHTS, RIGHTS-DATE, RIGHTS-URI is an example of structured metadata. VorbisComments are inherently unstructured, and this should be respected. Structured metadata belongs in a different stream, such as XML (using [[Metadata#XMLEmbedding|XMLEmbedding]]).

==== Improving existing fields proposal ====
Similar to the DATE tag above, we have generally recommended that a URL uniquely identifying the license be included in the LICENSE field to allow machine identification of the license. This is in agreement with the proposal in the Creative Commons wiki. Since the COPYRIGHT field is a human-readable statement of the copyright, like the proposed RIGHTS tag above, some people include a license url there. Therefore if a url can't be found in a LICENSE tag if any, applications should use one from the COPYRIGHT tag, if any. Contact information for verification, attribution, relicensing, etc. can be obtained from the COPYRIGHT field, but Creative Commons also recommend a separate CONTACT tag for this information. This is reasonable, so we propose it be included.

=== Geo Location fields ===

The existing LOCATION field is meant to carry a human readable location for the recording/creation of the media file.

Having geographical coordinates according to [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84] can be useful as well, especially in a form that can be machine parsed. The agreed format is similar to this [http://en.wikipedia.org/wiki/Geo_(microformat) geo microformat]:

GEO_LOCATION= ''latitude'' ; ''longitude'' [; ''elevation'' ]

where each value is a fixed point decimal number formatted in the C locale with a period (.) for the radix. Values are separated with a ';' and white space is not significant. The elevation is optional.

''latitude'' is the geo latitude location of where the media has been recorded or produced in decimal degrees according to WGS84 (zero at the equator, negative values for southern latitudes) (C double).

''longitude'' is the geo longitude location of where the media has been recorded or produced in decimal degrees according to WGS84 (zero at the prime meridian in Greenwich/UK, negative values for western longitudes). (C double).

''elevation'' is the geo elevation of where the media has been recorded or produced in meters according to WGS84 (zero is average sea level) (C double).

=== Replay Gain ===

The REPLAYGAIN_* fields implement the Replay Gain proposal for storing a track relative volume adjustment, which can be used to "fix" quiet or loud sounding Vorbis or FLAC streams. The set of tags is intended to be machine parsed, and has the following form:
<pre>
REPLAYGAIN_TRACK_GAIN=-7.03 dB
REPLAYGAIN_TRACK_PEAK=1.21822226
REPLAYGAIN_ALBUM_GAIN=-6.37 dB
REPLAYGAIN_ALBUM_PEAK=1.21822226
</pre>

See http://www.replaygain.org/ for detailed information about Replay Gain and how the different values are calculated.

=== Tantalos resource ID ===
Tantalos is a protocol to auto locate and access content in a network scope (normally 'LAN' but can also be bigger like 'company network'). It uses UUIDs to identify resources. There are two groups of those UUIDs: IDs generated using the meta data of the track and IDs generated in some other way (for example random IDs, see UUID specs). The later group may need to be passed with the track. The VCLT Playlist format (see below) uses 'HASH={UUID}id...' with hex-dash format for this (HASH={UUID}e278173d-4d6d-4c66-95ec-4ec85eedc7d1).
--[[User:Ph3-der-loewe|Ph3-der-loewe]] 02:05, 13 December 2011 (PST)

== Other (non-proposed field names) ==
=== VCLT playlist format ===
The VCLT playlist format uses some ''keys'' which look like VorbisComments but they aren't nor they are proposed to become (expect for HASH). This includes the keys STREAMURL, FILENAME, FILEURL, LENGTH, HASH (see above for this one), SIGNALINFO, AUDIOINFO and OFFSET. You can find more infos about those at [https://bts.keep-cool.org/wiki/Specs/VCLT https://bts.keep-cool.org/wiki/Specs/VCLT].

== Implementations ==

* [http://sbooth.org/importers/ OggImporter] – imports Ogg Vorbis and Ogg FLAC files to Spotlight.
* vorbiscomment – a commandline tool, part of [[VorbisTools]].
* [http://www.xiph.org/oggz/ oggz-comment] – a commandline tool, part of [[Oggz]] tool. It can add comments to multitrack and video files.

Chapter Extension

2012-10-12T18:03:09Z

Martin.leese: Zapped blank line

Chapters are a means of providing direct and semantically relevant navigation points for a media file. On particular use case are so-called [http://en.wikipedia.org/wiki/Enhanced_podcast "enhanced podcasts"], i.e. audio files with additional chapter markers.

Chapters are typically provided for a recorded file, not for a live resource.

Since chapters are used for navigation - in particular to avoid having to listen to large amounts of undesired content in order to get to desired content - it is important that the information about chapters is available at the start of a media file to be able to be displayed without having to decode the media file. Therefore, we regard chapters as header-style metadata.

Header-style metadata has traditionally been transported in [[VorbisComment]] headers inside Ogg.

== Format ==

We therefore propose an extensions to VorbisComment for transporting chapters. We introduce VorbisComment fields called CHAPTERxxx and CHAPTERxxxNAME with xxx being a number between 000 and 999. (1000 chapters are assumed to be sufficient.)

The value for the CHAPTERxxx field name is the start time of the chapter (Hour:Min:DecimalSeconds). See the [[#Examples|examples]] below.

The value for the CHAPTERxxxNAME field name is just a text string (8 bit clean UTF-8 encoded values, as is required for VorbisComments).

This should basically support the same input format that [http://savvyadmin.com/adding-chapters-to-videos-using-mkv-containers/ Matroska chapters] support, too.

== Examples ==

An example chapter file with two sequential chapters:

CHAPTER001=00:00:00.000
CHAPTER001NAME=Chapter 1
CHAPTER002=00:05:00.000
CHAPTER002NAME=Chapter 2

== Further Fields ==

Other fields can also be used to support enhanced podcasts:

* a field to extend chapters with a url to navigate to while listening to a chapter of a podcast:

CHAPTERxxxURL=http://...

== WebVTT ==

We expect people may also want support for hierarchically structured chapters with subchapters etc. This specification does not support this need. We recommend making use of WebVTT as a chapter format specification to satisfy this need. At a future time we expect a mapping of WebVTT into Ogg to allow for embedding of such files into Ogg, too.

WebVTT is a more modern means of specifying chapters [http://dev.w3.org/html5/webvtt/#webvtt-file-using-chapter-title-text that use cues with chapter titles] and can deal with time overlapping cues.

TransOgg

2012-09-28T16:32:32Z

Martin.leese: I lied (it didn't work correctly under Preview)

{{DISPLAYTITLE:transOgg}}
[[Image:proposed-transogg-logo.png|415px|right]]

= What is transOgg? =

For a long time there have been discussions of what we in Xiph would change in the Ogg container once we considered it appropriate to break spec. transOgg is an updated Ogg container (ie Ogg v 2) that makes some changes to the
Ogg transport layer and more directly tackles metadata. [[TransOggChangesFromOgg|transOgg: Changes from Ogg]] summarizes the major changes from the original Ogg container design.
This page presents an overview of nebulous transOgg design points and rationale.

As of today, transOgg exists only in the form of the whitepapers and structure proposals here. This spec is only in the very early stages of being written. No code exists as yet.

= Design Points =

In no particular order:

* transOgg is degined for local storage and packet-based transport. Some intended uses include:
** HTTP push/pull streaming (eg, HTML5, icecast/shoutcast).
** local file storage (eg, digital video storage and online distribution)
** physical media (eg, digital video distribution on optical media)
** packet broadcast (eg, UDP multicast, encrypted multicast)

* transOgg is designed for variable, unpredictably sized data payloads with no minumum or maximum size.

* The transOgg container is structurally designed for streaming (both live and progressive download). It is not possible to construct a valid transOgg stream that is unsuitable for streaming.

* transOgg defines two steam types: continuous-time and discontinuous-time. Continuous-time streams are gapless media such as video and audio. Discontinuous-time streams are media types with unpredictably or irregularly placed data, such as subtitles and timed metadata.

* transOgg metadata is structurally encapsulated into the transport stream but located at fixed, predictable positions (excepting streamed metadata, which are treated as a discontinuous stream).

* transOgg retains Ogg's flat page structure. The new/tweaked page primitive is a blend of Ogg pages, Matroska clusters/blocks and NUT packets. Achievable minimum overhead drops to under .04%; practical overhead improves upon NUT, Ogg and Matroska.

* A transOgg stream always captures and begins demux within 128kB maximum. Fine-grained capture is necessary for efficient streaming, seeking and scrubbing. The overhead tradeoff of a frequent capture pattern is negligable and fully offset by other improvements.

* Multiplexing of multiple elementary streams is performed by interleaving at the page level. The multiplexing algorithm is fully specified, deterministic and delivers optimal buffering behavior. There is no educated guessing or multiple possible practices.

* transOgg buffering is simple and explicitly specified.

* transOgg implements nonlinear features such as menus, chapters, loop points, and branch points out of its linear stream transport by borrowing from CMML, Skeleton and Matroska's EBML metadata specification.

* Valid transOgg streams may be concatenated to form a new, valid transOgg stream. Mandatory reverse linkage at the end of each stream eliminates the need for interpolated bisection search when opening concatenated streams. Cross-link metadata provides file-global indexing and chaptering for chained streams.

* transOgg metadata begins and ends every stream. Metadata is mandatory, fully specified, and part of 'container knowledge'.
** A transOgg stream must begin with the master metadata header. This master header is the first page[s] of the physical transOgg bitstream as well as the logical master metadata stream.
** The metadata stream is a discontinuous stream that may provide additional timed metadata and events throughout the stream, similar to NUT 'info packets'.
** A transOgg stream must end with metadata footer page[s] that provide, among other things, reverse linkage to the beginning of the stream.
** Tags (user contributed metadata) and Cues (the index) may appear at the head of the stream or in the footer, as may any other metadata elements that could not be known before stream end in a live stream (eg, duration). Single-pass creation tools write these elements in the footer metadata. Tools can later move these elements to the header metadata. All other metadata elements may appear only in the header.

* Headerless capture, multicast, and stateless unicast MAY be supported within the metadata stream using "rolling headers", similar to the "rolling intra" mechanism proposed for the Theora videocodec. This allows stream capture and playback in a bounded timeperiod without OOB transmission of headers or bitrate spikes. It also facilitates file recovery in the event the stream headers are lost.

* Structural codec metadata, such as timebase, keyframing, coding delay, page duration, etc, are replicated in the transOgg container. Unlike Ogg (and to a lesser degree Matroska), no knowledge must be queried or assumed based on the specific codecs in use inorder to mux, demux, remux, repaginate, transmux, or seek in a bitstream.

* As in NUT, all streams have their own rational timebase. The encoding used is a parameterized generalization of Ogg granule positions. The granule timebase and parameters are fully specified and declared in the container. The granule mechanism is capable of exact sample positioning without approximation, expressing PTS and DTS of out-of-order encodings, preroll/delay of keyframe-lesscodecs, and distance from last syncpoint.

* All encapsulated packets are stamped with full DTS, PTS, duration, delay, and syncpoint distance.

* Whenever possible, the transOgg specification presents a single, correct, optimal MUST behavior. Whenever possible, the container design seeks to make MUST behaviors structural. We avoid handwaving essential behaviors into 'best practices' documents 'to be specified later'.

* the core transOgg container seeks to avoid optional structures, switches, code paths, and features in its framing mechanisms. Optional structures and features are acceptable (and necessary) within metadata.

= High level design =

The high level transOgg design consists of a transport, metadata, and
specified practices. These pieces are conceptually seperable, but the
container cannot succeed missing any one.

== Transport ==

Transport is the mechanism of encapsulating and delivering data.
transOgg uses a modified/updated Ogg page mechanism for data and
metadata delivery.

Transport benefits from a simple, fixed encoding. Optional features,
arbitrary extensibility, recursive or non-flat heirarchy, and
conditional semantic encoding are undesirable complications in a low
level transport and should be used only when clearly advantageous or
unavoidable. Specifying transport as a self-contained layer also
seperates correct transport behavior and corner cases from the rest of
the container behavior.

Raw A/V media is fundamentally time-linear in atomic form. Networks
and storage media deliver data for consumption in a time-linear stream
of bytes. Both suggest that a linear encoding is optimal for the
low-level encapsulation. Metadata can build non-linear presentation
from linear segments. Nonlinear structural metadata appears at the
beginning and end of the stream; as such, this metadata can also be
placed in the linear transport easily as the beginning and end of
data. Encapsulating metadata in the transport like the streaming data
also makes it trivial to support streamed metadata and 'rolling
headers' using preexisting transport mechanisms. (*-- discuss both
chaining and multi-segment; metadata that can reach across segments?
etc?)

== Metadata ==

Metadata is everything in a stream/file that is not the media stream
itself. transOgg proposes use a packed encoding for metadata types unlikely to see much flux, and an extensibly-structured encoding for more free-form types (eg, Matroska-style metadata in an EBML
encoding for stream tagging).

Metadata encompasses a number of semantically quite different
concepts, eg:

* 1: data about how the individual streams are encoded and encapsulated (codec id, timebase, continuous/discontinuous encoding, codec private data, etc). This metadata is essential to base container operation and must function as container knowledge. It is always located in a fixed position at the beginning of the file as it must be read to bootstrap container operation.

* 2: data about navigating the file as it's currently arranged (linkages, indexing, chapters). This data is either essential to high-level container operation or essential to the application depending on how the implementation abstractions work out.

* 3: data about how the streams are presented for playback (langauge, primary angle, available soundtrack languages, menus). This data is needed by the application.

* 4: user-supplied comments, one-shot auxiliary data (tags, album art). This data is needed by the application and the user.

Each kind of metadata shares some basic traits. It is heirarchical,
largely conditional, and benefits from a rich stable of optional
elements to be used as appropraite. It is also likely that aside from
the MUST elements required for playback (mostly from list 1), not all
metadata will be interesting to all players. An obvious use case is a
memory and CPU constrained mobile device with no bitmapped display
which would want to entirely ignore/skip large album art chunks.

== Specified practices ==

Specified practices provide the instruction manual for proper use of
the container system in all cases where the container structure allows
multiple behavioral or encoding possibilities. 'best practices' is a
more common term, however 'best' connotes that such guidelines are
merely suggestive. Specified practices are effectively MUST clauses
that govern proper behavior rather than valid data.

Specified practices are an especially weak point of current FOSS
container offerings. Developers of open projects often value a system
that offers many equivalent ways of performing a task, and leave it to
higher-level developers (or worse, the user) to somehow make an
informed decision of how to proceed. In the container space, this is
undesirable bordering on disaster; 'more' is 'less'.

To choose an absurd example, it might be technologically nifty to be
able to place an index into the middle of a file, but what could it
possibly accomplish? Absurd flexibility results in absurd bugs. When
absurd or clearly suboptimal choices are structurally possible, the
spec should not be silent on the subject. The spec MUST explicitly
address allowed and disallowed behavior to the most complete degree
achievable.

= Proposals / Commentary Requested =

transOgg is a specification in the early stages of design. As such, we're soliciting feedback on specific design proposals below, with more to be added over time as the design process approaches new milestones.

* [[TransOgg_Seeking_Proposals]]: Three proposed seeking mechanism variants for transOgg.

= Specification =

* [[TransOgg_Page]]: Specification of transOgg page primitive
* [[TransOgg_Transport]]: Specification of transOgg stream
* [[TransOgg_Metadata]]: Specification of transOgg stream metadata

TransOgg

2012-09-28T16:28:42Z

Martin.leese: Added {{DISPLAYTITLE:transOgg}}. Changes HTML <title> tag, but not article title. Should work when Wiki upgraded to 1.7.

{{DISPLAYTITLE:transOgg}}
[[Image:proposed-transogg-logo.png|415px|right]]

Due to limitations of wiki-syntax, it should be noted that this page cannot be correctly titled 'transOgg'. The 't' in 'transOgg' is lowercase.

= What is transOgg? =

For a long time there have been discussions of what we in Xiph would change in the Ogg container once we considered it appropriate to break spec. transOgg is an updated Ogg container (ie Ogg v 2) that makes some changes to the
Ogg transport layer and more directly tackles metadata. [[TransOggChangesFromOgg|transOgg: Changes from Ogg]] summarizes the major changes from the original Ogg container design.
This page presents an overview of nebulous transOgg design points and rationale.

As of today, transOgg exists only in the form of the whitepapers and structure proposals here. This spec is only in the very early stages of being written. No code exists as yet.

= Design Points =

In no particular order:

* transOgg is degined for local storage and packet-based transport. Some intended uses include:
** HTTP push/pull streaming (eg, HTML5, icecast/shoutcast).
** local file storage (eg, digital video storage and online distribution)
** physical media (eg, digital video distribution on optical media)
** packet broadcast (eg, UDP multicast, encrypted multicast)

* transOgg is designed for variable, unpredictably sized data payloads with no minumum or maximum size.

* The transOgg container is structurally designed for streaming (both live and progressive download). It is not possible to construct a valid transOgg stream that is unsuitable for streaming.

* transOgg defines two steam types: continuous-time and discontinuous-time. Continuous-time streams are gapless media such as video and audio. Discontinuous-time streams are media types with unpredictably or irregularly placed data, such as subtitles and timed metadata.

* transOgg metadata is structurally encapsulated into the transport stream but located at fixed, predictable positions (excepting streamed metadata, which are treated as a discontinuous stream).

* transOgg retains Ogg's flat page structure. The new/tweaked page primitive is a blend of Ogg pages, Matroska clusters/blocks and NUT packets. Achievable minimum overhead drops to under .04%; practical overhead improves upon NUT, Ogg and Matroska.

* A transOgg stream always captures and begins demux within 128kB maximum. Fine-grained capture is necessary for efficient streaming, seeking and scrubbing. The overhead tradeoff of a frequent capture pattern is negligable and fully offset by other improvements.

* Multiplexing of multiple elementary streams is performed by interleaving at the page level. The multiplexing algorithm is fully specified, deterministic and delivers optimal buffering behavior. There is no educated guessing or multiple possible practices.

* transOgg buffering is simple and explicitly specified.

* transOgg implements nonlinear features such as menus, chapters, loop points, and branch points out of its linear stream transport by borrowing from CMML, Skeleton and Matroska's EBML metadata specification.

* Valid transOgg streams may be concatenated to form a new, valid transOgg stream. Mandatory reverse linkage at the end of each stream eliminates the need for interpolated bisection search when opening concatenated streams. Cross-link metadata provides file-global indexing and chaptering for chained streams.

* transOgg metadata begins and ends every stream. Metadata is mandatory, fully specified, and part of 'container knowledge'.
** A transOgg stream must begin with the master metadata header. This master header is the first page[s] of the physical transOgg bitstream as well as the logical master metadata stream.
** The metadata stream is a discontinuous stream that may provide additional timed metadata and events throughout the stream, similar to NUT 'info packets'.
** A transOgg stream must end with metadata footer page[s] that provide, among other things, reverse linkage to the beginning of the stream.
** Tags (user contributed metadata) and Cues (the index) may appear at the head of the stream or in the footer, as may any other metadata elements that could not be known before stream end in a live stream (eg, duration). Single-pass creation tools write these elements in the footer metadata. Tools can later move these elements to the header metadata. All other metadata elements may appear only in the header.

* Headerless capture, multicast, and stateless unicast MAY be supported within the metadata stream using "rolling headers", similar to the "rolling intra" mechanism proposed for the Theora videocodec. This allows stream capture and playback in a bounded timeperiod without OOB transmission of headers or bitrate spikes. It also facilitates file recovery in the event the stream headers are lost.

* Structural codec metadata, such as timebase, keyframing, coding delay, page duration, etc, are replicated in the transOgg container. Unlike Ogg (and to a lesser degree Matroska), no knowledge must be queried or assumed based on the specific codecs in use inorder to mux, demux, remux, repaginate, transmux, or seek in a bitstream.

* As in NUT, all streams have their own rational timebase. The encoding used is a parameterized generalization of Ogg granule positions. The granule timebase and parameters are fully specified and declared in the container. The granule mechanism is capable of exact sample positioning without approximation, expressing PTS and DTS of out-of-order encodings, preroll/delay of keyframe-lesscodecs, and distance from last syncpoint.

* All encapsulated packets are stamped with full DTS, PTS, duration, delay, and syncpoint distance.

* Whenever possible, the transOgg specification presents a single, correct, optimal MUST behavior. Whenever possible, the container design seeks to make MUST behaviors structural. We avoid handwaving essential behaviors into 'best practices' documents 'to be specified later'.

* the core transOgg container seeks to avoid optional structures, switches, code paths, and features in its framing mechanisms. Optional structures and features are acceptable (and necessary) within metadata.

= High level design =

The high level transOgg design consists of a transport, metadata, and
specified practices. These pieces are conceptually seperable, but the
container cannot succeed missing any one.

== Transport ==

Transport is the mechanism of encapsulating and delivering data.
transOgg uses a modified/updated Ogg page mechanism for data and
metadata delivery.

Transport benefits from a simple, fixed encoding. Optional features,
arbitrary extensibility, recursive or non-flat heirarchy, and
conditional semantic encoding are undesirable complications in a low
level transport and should be used only when clearly advantageous or
unavoidable. Specifying transport as a self-contained layer also
seperates correct transport behavior and corner cases from the rest of
the container behavior.

Raw A/V media is fundamentally time-linear in atomic form. Networks
and storage media deliver data for consumption in a time-linear stream
of bytes. Both suggest that a linear encoding is optimal for the
low-level encapsulation. Metadata can build non-linear presentation
from linear segments. Nonlinear structural metadata appears at the
beginning and end of the stream; as such, this metadata can also be
placed in the linear transport easily as the beginning and end of
data. Encapsulating metadata in the transport like the streaming data
also makes it trivial to support streamed metadata and 'rolling
headers' using preexisting transport mechanisms. (*-- discuss both
chaining and multi-segment; metadata that can reach across segments?
etc?)

== Metadata ==

Metadata is everything in a stream/file that is not the media stream
itself. transOgg proposes use a packed encoding for metadata types unlikely to see much flux, and an extensibly-structured encoding for more free-form types (eg, Matroska-style metadata in an EBML
encoding for stream tagging).

Metadata encompasses a number of semantically quite different
concepts, eg:

* 1: data about how the individual streams are encoded and encapsulated (codec id, timebase, continuous/discontinuous encoding, codec private data, etc). This metadata is essential to base container operation and must function as container knowledge. It is always located in a fixed position at the beginning of the file as it must be read to bootstrap container operation.

* 2: data about navigating the file as it's currently arranged (linkages, indexing, chapters). This data is either essential to high-level container operation or essential to the application depending on how the implementation abstractions work out.

* 3: data about how the streams are presented for playback (langauge, primary angle, available soundtrack languages, menus). This data is needed by the application.

* 4: user-supplied comments, one-shot auxiliary data (tags, album art). This data is needed by the application and the user.

Each kind of metadata shares some basic traits. It is heirarchical,
largely conditional, and benefits from a rich stable of optional
elements to be used as appropraite. It is also likely that aside from
the MUST elements required for playback (mostly from list 1), not all
metadata will be interesting to all players. An obvious use case is a
memory and CPU constrained mobile device with no bitmapped display
which would want to entirely ignore/skip large album art chunks.

== Specified practices ==

Specified practices provide the instruction manual for proper use of
the container system in all cases where the container structure allows
multiple behavioral or encoding possibilities. 'best practices' is a
more common term, however 'best' connotes that such guidelines are
merely suggestive. Specified practices are effectively MUST clauses
that govern proper behavior rather than valid data.

Specified practices are an especially weak point of current FOSS
container offerings. Developers of open projects often value a system
that offers many equivalent ways of performing a task, and leave it to
higher-level developers (or worse, the user) to somehow make an
informed decision of how to proceed. In the container space, this is
undesirable bordering on disaster; 'more' is 'less'.

To choose an absurd example, it might be technologically nifty to be
able to place an index into the middle of a file, but what could it
possibly accomplish? Absurd flexibility results in absurd bugs. When
absurd or clearly suboptimal choices are structurally possible, the
spec should not be silent on the subject. The spec MUST explicitly
address allowed and disallowed behavior to the most complete degree
achievable.

= Proposals / Commentary Requested =

transOgg is a specification in the early stages of design. As such, we're soliciting feedback on specific design proposals below, with more to be added over time as the design process approaches new milestones.

* [[TransOgg_Seeking_Proposals]]: Three proposed seeking mechanism variants for transOgg.

= Specification =

* [[TransOgg_Page]]: Specification of transOgg page primitive
* [[TransOgg_Transport]]: Specification of transOgg stream
* [[TransOgg_Metadata]]: Specification of transOgg stream metadata

OpusFAQ

2012-09-12T20:04:44Z

Martin.leese: /* What is Opus? Who created it? */ Tense

[[Image:Opus logo trans.png|right]]

== General Questions ==

=== What is Opus? Who created it? ===

Opus is a totally open, royalty-free, highly versatile audio codec. It is primarily designed for interactive speech and music transmission over the Internet, but is also applicable to storage and streaming applications. It incorporates technology from Skype's SILK codec and Xiph.Org's CELT codec. It has been standardized by the Internet Engineering Task Force (IETF) as '''[http://tools.ietf.org/html/rfc6716 RFC 6716]'''.

Opus has been in development since early 2007. Programmers associated with Xiph.Org, Skype, and several other organizations have contributed to its development and to the standardization process as part of the IETF's codec working group.

=== How does Opus compare to other codecs? ===

Opus is distinguished from most formats for high quality audio (AAC, Vorbis, MP3) by having low delay and it is distinguished from most low delay formats (G.711, GSM, Speex) by supporting high audio quality. It meets or exceeds existing codecs' quality across a wide range of bitrates, and it operates at lower delay than virtually any existing compressed format. Further, the Opus format itself and the reference implementation are available under liberal royalty-free licenses, making it easy to adopt, compatible with free software, and suitable for usage as part of the basic infrastructure of the Internet. See the Opus [http://opus-codec.org/comparison comparison page] for more details.

=== How do I use Opus? What programs support Opus? ===

Opus decoding support is now included in many applications, including Firefox and Foobar2000, as well as in frameworks such as GStreamer. For now, the best way to '''encode''' Opus files is to use the opusenc command-line tool from the opus-tools package. For real-time applications, Opus support should soon be available in the Google webrtc codebase. Opus is still a new codec, expect many more applications to support it in the near future.

=== Does Opus support higher sampling rates, such as 96 kHz or 192 kHz? ===

Yes and no. Opus encoding tools like opusenc will happily encode files that are sampled at 96 or 192 kHz. However, input files at these rates are internally converted to 48 kHz, and then only frequencies up to 20 kHz are encoded. The reason is simple: lossy codecs are designed to preserve audible details while discarding irrelevant information. Since the human ear can only hear up to 20 kHz at best (usually lower than that), frequency content above 20 kHz is the first thing to go. See Monty's [http://people.xiph.org/~xiphmont/demo/neil-young.html 24/192 Music Downloads ...and why they make no sense] for more details.

=== What are the licensing requirements? ===

The reference Opus source code is released under a three-clause BSD license, which is a very permissive Open Source license. Commercial use and distribution (including in proprietary software) is permitted, provided that some basic conditions specified in the license are met.

Opus is also covered by some patents, for which royalty-free usage rights are granted, under conditions that the authors believe are compatible with most (all?) open source licenses, including the GPL (v2 and v3). See the [http://www.opus-codec.org/license/ licensing page] for details.

=== Why make Opus free? ===

On the Internet, protocol and codec standards are part of the common infrastructure everyone builds upon. Most of the value of a high quality standard is the innovation and interoperation provided by the systems built on top of it. When a few parties have monopoly rights to monetize a standard, that infrastructure stops being so common—everyone else has more reason to use their own solution instead, increasing cost and reducing efficiency. Imagine a road system where each type of car could only drive on its own manufacturer's pavement. We all benefit from living in a world where all the roads are connected. This is why Opus, unlike many codecs, is free.

=== Is the SILK part of Opus compatible with the SILK implementation shipped in Skype? ===

No. The SILK codec, as submitted by Skype to the IETF, was heavily modified as part of its integration within Opus. The modifications are significant enough that it is not possible to just write a "translator" and even sharing code between Opus and the "old SILK" would be highly non-trivial.

=== Why not keep the SILK and CELT codecs separate? ===

Opus is more than just two independent codecs with a switch. In addition to a linear prediction "SILK mode" and a MDCT "CELT mode" it has a "hybrid mode," where speech frequencies up to 8 kHz are encoded with LP while those above 8 kHz are encoded with MDCT. This is what allows Opus to have such high speech quality around 32 kb/s. Another advantage of the integration is the ability to switch between these modes seamlessly, without any "glitch" and without any out-of-band signalling.

=== Now that Opus is standardized, will its development stop, or can it be further improved? ===

Unlike most ITU-T codecs, Opus is only defined in terms of its decoder. The encoder can keep evolving as long as the bitstream it produces can be decoded by the reference decoder. This is what made it possible for MP3 encoders to improve far beyond the original l3enc and the dist10 reference implementation. Although it is unlikely that Opus encoders will see such spectacular evolution, we certainly hope that future encoders will become much better than the reference encoder. In fact, there is already an [http://www.opus-codec.org/development/ experimental branch] that significantly improves on the reference encoder's quality.

=== Will all future Opus releases comply with the [http://tools.ietf.org/html/rfc6716 Opus specification]? ===

Yes.

=== In what way is Opus optimized for the Internet? ===

Opus being optimized for the Internet obviously means that it has good packet loss robustness and concealment, but it goes further. One of the first things we've been asked when designing Opus was to make the rate '''really''' adaptable because we never know what kind of rates will be available. This not only meant having a wide range of bitrates, but also being able to vary in small increments. This is why Opus scales from about 6 kb/s to 512 kb/s, in increments of 0.4 kb/s (one byte with 20 ms frames). The reason Opus can have more than 1200 possible bitrates spending 11 bits signalling the bitrate is because UDP already encodes the packet size. One last aspect is that Opus is simple to transport over RTP, as can be seen from [http://tools.ietf.org/html/draft-spittka-payload-rtp-opus Opus RTP payload format]. For example, it's possible to decode RTP packets without having even seen the SDP or any out-of-band signalling.

== Opus for Software developers ==

=== On what platforms does Opus run? ===

The Opus code base is written in C89 and should run on the vast majority of recent (and not so recent) CPUs. A few of the platforms on which Opus has been tested and is known to run include x86, x86-64, ARM, Itanium, Blackfin, and SPARC.

=== Is there a fixed-point implementation? ===

Yes; the fixed-point and floating-point decoder and encoder implementations are part of the same code base. The code defaults to float, so you need to configure with --enable-fixed-point (or defining FIXED_POINT if not using the configure script) to build the code for fixed-point.

=== Which implementation should I use? ===

While the implementation in RFC 6716 is what ''defines'' the standard, it is likely not the best and most up-to-date implementation. The [http://opus-codec.org/ Opus] website was set up for the purpose of continually improving the implementation— in terms of speed, encoding quality, device compatibility, etc— while still conforming to the standard. All Opus implementations are compatible by definition.

=== How is supporting Opus different from supporting Speex/G.711/MP3? ===

Opus has variable frame durations which can change on the fly, so an Opus decoder needs to be ready to accept packets with durations that are any multiple of 2.5ms up to a maximum of 120ms.

The opus encoder and decoder do not need to have matched sampling rates or channel counts. It is recommended to always just decode at the highest rate the hardware supports (e.g. 48kHz stereo) so the user gets the full quality of whatever the far end is sending.

=== My application doesn't work. Can anyone help me? ===

It's possible to get help, but before doing so, there are a few basic things to try:

* Implement the application with uncompressed audio instead of Opus. If it still doesn't work, then the problem isn't related to Opus.
* Read the [http://www.opus-codec.org/docs/ documentation].
* Read the opus_demo.c source code to see how to use the encoder and decoder.

If you still can't solve the problem, the best option is to ask for help on the [http://lists.xiph.org/mailman/listinfo/opus mailing list].

=== How do I report a bug? ===

If you think you have found a bug in Opus (and not in your application), please [https://trac.xiph.org/newticket?component=Opus file a bug report]. Please include a way for us to reproduce the problem. The best way to do this is to provide an input file, along with the opusenc/opusdec/opus_demo command line that causes the bug to occur. If the bug cannot be triggered by the command line tools, please provide a simple patch or C file that can help reproduce it. Please also provide any other relevant information, such as OS, CPU, build options, etc. Also, don't hesitate to also contact us on the [http://lists.xiph.org/mailman/listinfo/opus mailing list] or on [irc://irc.freenode.net/opus IRC].

=== What is Opus Custom? ===

Opus Custom is an '''optional''' part of the Opus standard that allows for sampling rates other than 8, 12, 16, 24, or 48 kHz and frame sizes other than multiples of 2.5 ms. Opus Custom requires additional out-of-band signalling that Opus does not normally require and disables many of Opus' coding modes. Also, because it is an optional part of the specification, using Opus Custom may lead to compatibility problems. For these reasons, its use is discouraged outside of very specific applications, e.g.:
* ultra low delay applications where synchronization with the soundcard buffer is important.
* low-power embedded applications where compatibility with others is not important.

For almost all other types of applications, Opus Custom should not be used.

=== How do I use 44.1 kHz or some other sampling rate not directly supported by Opus? ===

Tools which read or write Opus should interoperate with other sampling rates by transparently performing sample rate conversion behind the scenes whenever necessary. In particular, software developers should not use Opus Custom for 44.1 kHz support, except in the very specific circumstances outlined above.

Note that it's generally preferable for a decoder to output at 48kHz even when you know the original input was 44.1kHz, not only because you can skip resampling but also because many inexpensive audio interfaces have poor quality output for 44.1k.

The opus-tools package source code contains a small, high quality, high performance, BSD licensed resampler which can be used where resampling is required.

=== Forward Error correction (FEC) doesn't appear to do anything! HELP! ===

The inband FEC feature of Opus helps reduce the harm of packet loss by encoding some information about the prior packet.

In order to make use of inband FEC the decoder must delay its output by at least one frame so that it can call the decoder with the decode_fec argument on the ''next'' frame in order to reconstruct the missed frame. This works best if it's integrated with a jitter buffer.

FEC is only used by the encoder under certain conditions: the feature must be enabled via the OPUS_SET_INBAND_FEC CTL, the encoder must be told to expect loss via the OPUS_SET_PACKET_LOSS_PERC CTL, and the codec must be operated in any of the linear prediction or Hybrid modes. Frame durations of <10ms and very high bitrates will use the MDCT modes, where FEC is not available.

Even when FEC is not used, telling the encoder about the expected level of loss will help it make more intelligent decisions. By default the implementation assumes there is no loss.

=== I can't use malloc or much stack on my embedded platform how do I make Opus work? ===

A normal build of libopus only uses malloc/free in the _create() and _destroy() calls, so Opus is safe for realtime use so long as the codec state is pre-created.

In order to build Opus without any reference to malloc/free at all use init() calls rather than the create() calls in your application and compile with <tt>CFLAGS="-DOVERRIDE_OPUS_ALLOC -DOVERRIDE_OPUS_FREE -D'opus_alloc(x)=NULL' -D'opus_free(x)=NULL' "</tt> you will get a build which does not use malloc/free.

If libopus is built with -DNONTHREADSAFE_PSEUDOSTACK (instead of VAR_ARRAYS, or USE_ALLOCA) it will use a user provided block of heap instead of stack for many things resulting in much lower the stack usage. However this makes the resulting library non-threadsafe and is not recommend on anything except limited embedded platforms.

TransOgg

2012-09-03T18:29:42Z

Martin.leese: /* What is transOgg? */ Typo

Due to limitations of wiki-syntax, it should be noted that this page cannot be correctly titled 'transOgg'. The 't' in 'transOgg' is lowercase.

= What is transOgg? =

For a long time there have been discussions of what we in Xiph would change in the Ogg container once we considered it appropriate to break spec. transOgg is an updated Ogg container (ie Ogg v 2) that makes some changes to the
Ogg transport layer and more directly tackles metadata. [[TransOggChangesFromOgg|transOgg: Changes from Ogg]] summarizes the major changes from the original Ogg container design.
This page presents an overview of nebulous transOgg design points and rationale.

As of today, transOgg exists only in the form of the whitepapers and structure proposals here. This spec is only in the very early stages of being written. No code exists as yet.

= Design Points =

In no particular order:

* transOgg is degined for local storage and packet-based transport. Some intended uses include:
** HTTP push/pull streaming (eg, HTML5, icecast/shoutcast).
** local file storage (eg, digital video storage and online distribution)
** physical media (eg, digital video distribution on optical media)
** packet broadcast (eg, UDP multicast, encrypted multicast)

* transOgg is designed for variable, unpredictably sized data payloads with no minumum or maximum size.

* The transOgg container is structurally designed for streaming (both live and progressive download). It is not possible to construct a valid transOgg stream that is unsuitable for streaming.

* transOgg defines two steam types: continuous-time and discontinuous-time. Continuous-time streams are gapless media such as video and audio. Discontinuous-time streams are media types with unpredictably or irregularly placed data, such as subtitles and timed metadata.

* transOgg metadata is structurally encapsulated into the transport stream but located at fixed, predictable positions (excepting streamed metadata, which are treated as a discontinuous stream).

* transOgg retains Ogg's flat page structure. The new/tweaked page primitive is a blend of Ogg pages, Matroska clusters/blocks and NUT packets. Achievable minimum overhead drops to under .04%; practical overhead improves upon NUT, Ogg and Matroska.

* A transOgg stream always captures and begins demux within 128kB maximum. Fine-grained capture is necessary for efficient streaming, seeking and scrubbing. The overhead tradeoff of a frequent capture pattern is negligable and fully offset by other improvements.

* Multiplexing of multiple elementary streams is performed by interleaving at the page level. The multiplexing algorithm is fully specified, deterministic and delivers optimal buffering behavior. There is no educated guessing or multiple possible practices.

* transOgg buffering is simple and explicitly specified.

* transOgg implements nonlinear features such as menus, chapters, loop points, and branch points out of its linear stream transport by borrowing from CMML, Skeleton and Matroska's EBML metadata specification.

* Valid transOgg streams may be concatenated to form a new, valid transOgg stream. Mandatory reverse linkage at the end of each stream eliminates the need for interpolated bisection search when opening concatenated streams. Cross-link metadata provides file-global indexing and chaptering for chained streams.

* transOgg metadata begins and ends every stream. Metadata is mandatory, fully specified, and part of 'container knowledge'.
** A transOgg stream must begin with the master metadata header. This master header is the first page[s] of the physical transOgg bitstream as well as the logical master metadata stream.
** The metadata stream is a discontinuous stream that may provide additional timed metadata and events throughout the stream, similar to NUT 'info packets'.
** A transOgg stream must end with metadata footer page[s] that provide, among other things, reverse linkage to the beginning of the stream.
** Tags (user contributed metadata) and Cues (the index) may appear at the head of the stream or in the footer, as may any other metadata elements that could not be known before stream end in a live stream (eg, duration). Single-pass creation tools write these elements in the footer metadata. Tools can later move these elements to the header metadata. All other metadata elements may appear only in the header.

* Headerless capture, multicast, and stateless unicast MAY be supported within the metadata stream using "rolling headers", similar to the "rolling intra" mechanism proposed for the Theora videocodec. This allows stream capture and playback in a bounded timeperiod without OOB transmission of headers or bitrate spikes. It also facilitates file recovery in the event the stream headers are lost.

* Structural codec metadata, such as timebase, keyframing, coding delay, page duration, etc, are replicated in the transOgg container. Unlike Ogg (and to a lesser degree Matroska), no knowledge must be queried or assumed based on the specific codecs in use inorder to mux, demux, remux, repaginate, transmux, or seek in a bitstream.

* As in NUT, all streams have their own rational timebase. The encoding used is a parameterized generalization of Ogg granule positions. The granule timebase and parameters are fully specified and declared in the container. The granule mechanism is capable of exact sample positioning without approximation, expressing PTS and DTS of out-of-order encodings, preroll/delay of keyframe-lesscodecs, and distance from last syncpoint.

* All encapsulated packets are stamped with full DTS, PTS, duration, delay, and syncpoint distance.

* Whenever possible, the transOgg specification presents a single, correct, optimal MUST behavior. Whenever possible, the container design seeks to make MUST behaviors structural. We avoid handwaving essential behaviors into 'best practices' documents 'to be specified later'.

* the core transOgg container seeks to avoid optional structures, switches, code paths, and features in its framing mechanisms. Optional structures and features are acceptable (and necessary) within metadata.

= High level design =

The high level transOgg design consists of a transport, metadata, and
specified practices. These pieces are conceptually seperable, but the
container cannot succeed missing any one.

== Transport ==

Transport is the mechanism of encapsulating and delivering data.
transOgg uses a modified/updated Ogg page mechanism for data and
metadata delivery.

Transport benefits from a simple, fixed encoding. Optional features,
arbitrary extensibility, recursive or non-flat heirarchy, and
conditional semantic encoding are undesirable complications in a low
level transport and should be used only when clearly advantageous or
unavoidable. Specifying transport as a self-contained layer also
seperates correct transport behavior and corner cases from the rest of
the container behavior.

Raw A/V media is fundamentally time-linear in atomic form. Networks
and storage media deliver data for consumption in a time-linear stream
of bytes. Both suggest that a linear encoding is optimal for the
low-level encapsulation. Metadata can build non-linear presentation
from linear segments. Nonlinear structural metadata appears at the
beginning and end of the stream; as such, this metadata can also be
placed in the linear transport easily as the beginning and end of
data. Encapsulating metadata in the transport like the streaming data
also makes it trivial to support streamed metadata and 'rolling
headers' using preexisting transport mechanisms. (*-- discuss both
chaining and multi-segment; metadata that can reach across segments?
etc?)

== Metadata ==

Metadata is everything in a stream/file that is not the media stream
itself. transOgg proposes use a packed encoding for metadata types unlikely to see much flux, and an extensibly-structured encoding for more free-form types (eg, Matroska-style metadata in an EBML
encoding for stream tagging).

Metadata encompasses a number of semantically quite different
concepts, eg:

* 1: data about how the individual streams are encoded and encapsulated (codec id, timebase, continuous/discontinuous encoding, codec private data, etc). This metadata is essential to base container operation and must function as container knowledge. It is always located in a fixed position at the beginning of the file as it must be read to bootstrap container operation.

* 2: data about navigating the file as it's currently arranged (linkages, indexing, chapters). This data is either essential to high-level container operation or essential to the application depending on how the implementation abstractions work out.

* 3: data about how the streams are presented for playback (langauge, primary angle, available soundtrack languages, menus). This data is needed by the application.

* 4: user-supplied comments, one-shot auxiliary data (tags, album art). This data is needed by the application and the user.

Each kind of metadata shares some basic traits. It is heirarchical,
largely conditional, and benefits from a rich stable of optional
elements to be used as appropraite. It is also likely that aside from
the MUST elements required for playback (mostly from list 1), not all
metadata will be interesting to all players. An obvious use case is a
memory and CPU constrained mobile device with no bitmapped display
which would want to entirely ignore/skip large album art chunks.

== Specified practices ==

Specified practices provide the instruction manual for proper use of
the container system in all cases where the container structure allows
multiple behavioral or encoding possibilities. 'best practices' is a
more common term, however 'best' connotes that such guidelines are
merely suggestive. Specified practices are effectively MUST clauses
that govern proper behavior rather than valid data.

Specified practices are an especially weak point of current FOSS
container offerings. Developers of open projects often value a system
that offers many equivalent ways of performing a task, and leave it to
higher-level developers (or worse, the user) to somehow make an
informed decision of how to proceed. In the container space, this is
undesirable bordering on disaster; 'more' is 'less'.

To choose an absurd example, it might be technologically nifty to be
able to place an index into the middle of a file, but what could it
possibly accomplish? Absurd flexibility results in absurd bugs. When
absurd or clearly suboptimal choices are structurally possible, the
spec should not be silent on the subject. The spec MUST explicitly
address allowed and disallowed behavior to the most complete degree
achievable.

= Specification =

* [[TransOgg_Page]]: Specification of transOgg page primitive
* [[TransOgg_Transport]]: Specification of transOgg stream
* [[TransOgg_Metadata]]: Specification of transOgg stream metadata

Vorbis

2012-08-25T14:11:27Z

Martin.leese: Undo revision 13574 by Jenifferjones (talk) SPAM link

'''Vorbis''' is a patent-clear, fully open, general purpose audio encoding format standard that rivals or even surpasses the 'upcoming' generation of proprietary codecs ([[Wikipedia:Advanced Audio Coding|AAC]] and [[Wikipedia:TwinVQ|TwinVQ]], also known as VQF). There is no raw Vorbis stream defined, instead the Vorbis codec is typically used in the [[Ogg]] container format for audio files. Because for a long time the Ogg container was quasi exclusive for Vorbis people often refer to it as 'Ogg Vorbis'. Later the FLAC audio codec as well as the video codecs Theora and Dirac began to be used inside Ogg too. In 2010 the [[WebM]] format was defined using the Vorbis codec inside the WebM container.

libvorbis, a BSD-licensed source implementation of Vorbis as a library is available; See the [http://xiph.org/vorbis/ Ogg Vorbis page] for documentation, downloads and distribution terms.

Many hard- and software players support Ogg Vorbis; see [http://www.vorbis.com/ vorbis.com] or the links below for a list of all the players we know about.

== More information ==

* [[Vorbis Hardware]]: List of hardware-players supporting Ogg Vorbis
* [[Vorbis Software Players]]: List of media players that can play Ogg Vorbis
* [[Vorbis Software Encoders]]: List of libvorbis frontends
* [[Vorbis Decoders]]: List of decoders (e.g. Xiph, Tremor, JOrbis, etc)
* [[Vorbis Encoders]]: List of encoders (e.g. Xiph, aoTuV, GT, vorbis-java)
* [[Vorbis-tools]]: Reference tools maintained by Xiph.org
* [[Games that use Vorbis]]: List of games using Ogg Vorbis
* [[VorbisStreams]]: Stations streaming with the [[Vorbis]] codec
* [[VorbisCasts]]: Audiocasts publishing Ogg [[Vorbis]] feeds

== External links ==

* [http://www.vorbis.com/ Vorbis.com]
* [[Wikipedia: Vorbis]]
* [http://www.rjamorim.com/test/multiformat128/results.html 128kbps public listening test]
* [http://www.hydrogenaudio.org/forums/index.php?showtopic=35438 80kbps personal listening test]
* [http://www.hydrogenaudio.org/forums/index.php?showtopic=36465 180kbps personal listening test with classical music]
* [http://www.maresweb.de/listening-tests/mf-128-1/results.htm 128kbps public listening test]

[[Category:Vorbis]]

Icecast

2012-08-25T14:11:06Z

Martin.leese: Undo revision 13576 by Jenifferjones (talk) SPAM link

'''Icecast''' is an open source multi-platform streaming server. It supports [[Ogg]] [[Vorbis]], Ogg [[Theora]], and [[MP3]].

== External links ==

* [http://www.icecast.org/ Icecast homepage]
* [http://dir.xiph.org/index.php Stream directory]
* [http://www.nabble.com/Icecast-f2880.html Icecast archive / forum] - an Icecast mailing list archive that combines both user and dev lists. It is hosted by [http://www.nabble.com/ Nabble]. You can search or browse Icecast discussions here.

== Development ==

*trunk http://svn.xiph.org/icecast/trunk/icecast
*kh-branch http://svn.xiph.org/icecast/branches/kh/icecast
**diff to trunk
***fast pre-buffering aka burst-on-connect. State a burst size in bytes to indicate how much should be sent at listener connect.
***mp3 accepts artist and title separately on the url.
***program invocation at stream start and end, per mount based.
***on-demand relays, activated on first listener, disconnected when listenersfalls to 0. Available for master relays as well.
***multiple Ogg codec streaming. Current codecs handled are Theora, Vorbis, Speex, Writ.
***Clients are started at theora key frame if theora is being streamed.
***Added URL and command based listener authentication
***server xml reload, and reopen logging available via admin url
***slave startup re-organised so that relays are more independant
***on xml reload, active sources are updated as well
***When max-listeners reached, a HTTP 302 code can be sent to redirect clients to alternative slave hosts.
***authenticated relays, those that match the relay user/pass, bypass the max-listener check

== Wish List ==

As good ideas are never a waste, and for tracking purposes, please list here all the features you're missing in icecast trunk.

Note: please check that the feature you request is not already in trunk before posting !

* WebM streaming
* OggOpus streaming
* PUT method support
* Ponies

[[Category:Xiph-related Software]]

OpusFAQ

2012-08-22T18:42:24Z

Martin.leese: /* Who created Opus? */ Typos (OK, done now)

[[Image:Opus logo trans.png|right]]

== General Questions ==

=== What is Opus? ===

Opus is a format for compressing audio to efficiently transmit it across networks. Opus allows for music-grade high quality audio at low data rates while not delaying the signal much. Opus is distinguished from most formats for high quality audio (AAC, Vorbis, MP3) by having low delay and it is distinguished from most low delay formats (G.711, GSM, Speex) by supporting high audio quality. The Opus format itself and the reference implementation are available under liberal royalty-free licenses, making it easy to adopt, compatible with free software, and suitable for for usage as part of the basic infrastructure of the Internet.

=== Who created Opus? ===

Opus was created by combining Xiph.Org's CELT development codec and Skype's SILK codec as part of a cooperative effort in the IETF codec working group. Opus has been in development since early 2007 and will be published as the IETF standard '''[http://tools.ietf.org/html/rfc6716 RFC 6716]'''.

=== Why make Opus free? ===

On the Internet, protocol and codec standards are part of the common infrastructure everyone builds upon. Most of the value of a high quality standard is the innovation and interoperation provided by the systems built on top of it. When a few parties have monopoly rights to monetize a standard, that infrastructure stops being so common—everyone else has more reason to use their own solution instead, increasing cost and reducing efficiency. Imagine a road system where each type of car could only drive on its own manufacturer's pavement. We all benefit from living in a world where all the roads are connected. This is why Opus, unlike many codecs, is free.

=== Is the SILK part of Opus compatible with the SILK implementation shipped in Skype? ===

No. The SILK codec, as submitted by Skype to the IETF, was heavily modified as part of its integration within Opus. The modifications are significant enough that it is not possible to just write a "translator" and even sharing code between Opus and the "old SILK" would be highly non-trivial.

=== How do I use Opus / What programs use Opus? ===

=== What are the licensing requirements? ===

The reference Opus source code is released under a three-clause BSD license, which is a very permissive Open Source license. Commercial use and distribution (including in proprietary software) is permitted, provided that some basic conditions specified in the license are met.

Opus is also covered by some patents, for which royalty-free usage rights are granted, under conditions that the authors believe are compatible with most (all?) open source licenses, including the GPL (v2 and v3).

=== How does the quality of Opus compare to other codecs? ===

See the Opus [http://opus-codec.org/comparison comparison page] for more on this.

=== On what platforms does Opus run? ===

The Opus code base is written in C89 and should run on the vast majority of recent (and not so recent) CPUs. Opus has been tested and is known to run on the following (non-exhaustive list) platforms: x86, x86-64, ARM, Itanium, Blackfin, SPARC.

=== Is there a fixed-point implementation? ===

Yes, the fixed-point and floating-point decoder and encoder implementations are part of the same code base. The code defaults to float, so you need to configure with --enable-fixed-point (or defining FIXED_POINT if not using the configure script) to build the code for fixed-point.

=== Why not keep the SILK and CELT codecs separate? ===

Opus is more than just two independent codecs with a switch. It can not only run in "SILK mode" and in "CELT mode", but also in "hybrid mode" where speech frequencies up to 8 kHz are encoded with SILK while those above 8 kHz are encoded with CELT. This is what allows Opus to have such high speech quality around 32 kb/s. Another advantage of the integration is the ability to switch mode seamlessly. It is possible to change between all the modes without any "glitch" and without any out-of-band signalling.

=== Now that Opus is standardized, does it mean the development will stop? ===

Unlike most ITU-T codecs, Opus is only defined in terms of its decoder. The encoder can keep evolving as long as the bits it produces can be decoded by the reference decoder. This is what made it possible for MP3 encoders to improve far beyond the original l3enc and the dist10 reference implementation. Although it is unlikely that Opus encoders will see such spectacular evolution, we certainly hope that future encoders will become much better than the reference encoder. In fact, there is already an [http://www.opus-codec.org/development/ experimental branch] that significantly improve on the reference encoder's quality.

== Opus for Software developers ==

=== What is difference between supporting Opus and supporting Speex/G.711/MP3? ===

Opus has variable frame durations which can change on the fly, so an Opus decoder needs to be ready to accept packets with durations that are any multiple of 2.5ms up to a maximum of 120ms.

The opus encoder and decoder do not need to have matched sampling rates, bandwidths, or channel counts. Its recommended to always just decode at the highest rate the hardware supports (e.g. 48kHz stereo) so the user gets the full quality of whatever the far end is sending.

=== My application doesn't work. Can anyone help me? ===

It's possible to get help, but before doing so, there are a few basic things to try:

* Implement the application with uncompressed audio instead of Opus. If it still doesn't work, then the problem isn't related to Opus
* Read the [http://www.opus-codec.org/docs/ documentation]
* Read the opus_demo.c source code to see how to use the encoder and decoder

If it still doesn't work, the best option is to ask on the [http://lists.xiph.org/mailman/listinfo/opus mailing list]

=== Forward Error correction (FEC) doesn't appear to do anything! HELP! ===

The inband FEC feature of Opus helps reduce the harm of packet loss by encoding some information about the prior packet.

In order to make use of inband FEC the decoder must delay its output by at least one frame so that it can call the decoder with the decode_fec argument on the ''next'' frame in order to reconstruct the missed frame. This works best if it's integrated with a jitter buffer.

FEC is only used by the encoder under certain conditions: the feature must be enabled via the OPUS_SET_INBAND_FEC CTL, the encoder must be told to expect loss via the OPUS_SET_PACKET_LOSS_PERC CTL, and the codec must be operated in any of the linear prediction or Hybrid modes. Frame durations of <10ms and very high bitrates will use the MDCT modes, where FEC is not available.

Even when FEC is not used, telling the encoder about the level of loss will help it make more intelligent decisions. By default the implementation assumes there is no loss.

=== What is Opus Custom? ===

Opus Custom is an '''optional''' part of the Opus standard that allows for sampling rates other than 8, 12, 16, 24, or 48 kHz and frame sizes other than multiples of 2.5 ms. Opus Custom requires additional out-of-band signalling that Opus does not normally require and disables many of Opus' coding modes. Also, because it is an optional part of the specification, using Opus Custom may lead to compatibility problems. For these reasons, its use is discouraged outside of very specific applications, e.g.:
* ultra low delay applications where synchronization with the soundcard buffer is important.
* low-power embedded applications where compatibility with others is not important.

For almost all other types of applications, Opus Custom should not be used.

=== How do I use 44.1 kHz or some other sampling rate not directly supported by Opus? ===

Tools which read or write Opus should inter-work with other sampling rate by transparently performing sample rate conversion behind the scenes. It's generally preferable to run the output at 48kHz even when you know the original input was 44.1kHz because many inexpensive audio interfaces have poor quality output for 44.1k.

In particular, software developers should not use Opus Custom for 44.1 kHz support, except in the very specific circumstances outlined above.

The opus-tools package source code contains a small, high quality, high performance, BSD licensed resampler which can be used where resampling is required.

=== I can't use malloc or much stack on my embedded platform how do I make Opus work? ===

A normal build of libopus only uses malloc/free in the _create() and _destroy() calls, so Opus is safe for realtime use so long as the codec state is pre-created.

In order to build Opus without any reference to malloc/free at all use init() calls rather than the create() calls in your application and compile with <tt>CFLAGS="-DOVERRIDE_OPUS_ALLOC -DOVERRIDE_OPUS_FREE -D'opus_alloc(x)=NULL' -D'opus_free(x)=NULL' "</tt> you will get a build which does not use malloc/free.

If libopus is built with -DNONTHREADSAFE_PSEUDOSTACK (instead of VAR_ARRAYS, or USE_ALLOCA) it will use a user provided block of heap instead of stack for many things resulting in much lower the stack usage. However this makes the resulting library non-threadsafe and is not recommend on anything except limited embedded platforms.

=== Which implementation should I use? ===

While the implementation in the latest IETF draft (and eventually RFC) of Opus is what ''defines'' the standard, it is likely not the best and most up-to-date implementation. The [http://opus-codec.org/ Opus] website was set up for the purpose of continually improving the implementation— in terms of speed, encoding quality, device compatibility, etc— while still conforming to the standard. All Opus implementations are compatible by definition.

OpusFAQ

2012-08-22T18:41:25Z

Martin.leese: /* Who created Opus? */ It *is* a proposed standard, and soon *will be* a standard. See http://www.rfc-editor.org/auth48/rfc6716

[[Image:Opus logo trans.png|right]]

== General Questions ==

=== What is Opus? ===

Opus is a format for compressing audio to efficiently transmit it across networks. Opus allows for music-grade high quality audio at low data rates while not delaying the signal much. Opus is distinguished from most formats for high quality audio (AAC, Vorbis, MP3) by having low delay and it is distinguished from most low delay formats (G.711, GSM, Speex) by supporting high audio quality. The Opus format itself and the reference implementation are available under liberal royalty-free licenses, making it easy to adopt, compatible with free software, and suitable for for usage as part of the basic infrastructure of the Internet.

=== Who created Opus? ===

Opus was created by combining Xiph.Org's CELT development codec and Skype's SILK codec as part of a cooperative effort in the IETF codec working group. Opus has been in development since early 2007 and will be published as an IETF standard: '''[http://tools.ietf.org/html/rfc6716 RFC 6716]'''.

=== Why make Opus free? ===

On the Internet, protocol and codec standards are part of the common infrastructure everyone builds upon. Most of the value of a high quality standard is the innovation and interoperation provided by the systems built on top of it. When a few parties have monopoly rights to monetize a standard, that infrastructure stops being so common—everyone else has more reason to use their own solution instead, increasing cost and reducing efficiency. Imagine a road system where each type of car could only drive on its own manufacturer's pavement. We all benefit from living in a world where all the roads are connected. This is why Opus, unlike many codecs, is free.

=== Is the SILK part of Opus compatible with the SILK implementation shipped in Skype? ===

No. The SILK codec, as submitted by Skype to the IETF, was heavily modified as part of its integration within Opus. The modifications are significant enough that it is not possible to just write a "translator" and even sharing code between Opus and the "old SILK" would be highly non-trivial.

=== How do I use Opus / What programs use Opus? ===

=== What are the licensing requirements? ===

The reference Opus source code is released under a three-clause BSD license, which is a very permissive Open Source license. Commercial use and distribution (including in proprietary software) is permitted, provided that some basic conditions specified in the license are met.

Opus is also covered by some patents, for which royalty-free usage rights are granted, under conditions that the authors believe are compatible with most (all?) open source licenses, including the GPL (v2 and v3).

=== How does the quality of Opus compare to other codecs? ===

See the Opus [http://opus-codec.org/comparison comparison page] for more on this.

=== On what platforms does Opus run? ===

The Opus code base is written in C89 and should run on the vast majority of recent (and not so recent) CPUs. Opus has been tested and is known to run on the following (non-exhaustive list) platforms: x86, x86-64, ARM, Itanium, Blackfin, SPARC.

=== Is there a fixed-point implementation? ===

Yes, the fixed-point and floating-point decoder and encoder implementations are part of the same code base. The code defaults to float, so you need to configure with --enable-fixed-point (or defining FIXED_POINT if not using the configure script) to build the code for fixed-point.

=== Why not keep the SILK and CELT codecs separate? ===

Opus is more than just two independent codecs with a switch. It can not only run in "SILK mode" and in "CELT mode", but also in "hybrid mode" where speech frequencies up to 8 kHz are encoded with SILK while those above 8 kHz are encoded with CELT. This is what allows Opus to have such high speech quality around 32 kb/s. Another advantage of the integration is the ability to switch mode seamlessly. It is possible to change between all the modes without any "glitch" and without any out-of-band signalling.

=== Now that Opus is standardized, does it mean the development will stop? ===

Unlike most ITU-T codecs, Opus is only defined in terms of its decoder. The encoder can keep evolving as long as the bits it produces can be decoded by the reference decoder. This is what made it possible for MP3 encoders to improve far beyond the original l3enc and the dist10 reference implementation. Although it is unlikely that Opus encoders will see such spectacular evolution, we certainly hope that future encoders will become much better than the reference encoder. In fact, there is already an [http://www.opus-codec.org/development/ experimental branch] that significantly improve on the reference encoder's quality.

== Opus for Software developers ==

=== What is difference between supporting Opus and supporting Speex/G.711/MP3? ===

Opus has variable frame durations which can change on the fly, so an Opus decoder needs to be ready to accept packets with durations that are any multiple of 2.5ms up to a maximum of 120ms.

The opus encoder and decoder do not need to have matched sampling rates, bandwidths, or channel counts. Its recommended to always just decode at the highest rate the hardware supports (e.g. 48kHz stereo) so the user gets the full quality of whatever the far end is sending.

=== My application doesn't work. Can anyone help me? ===

It's possible to get help, but before doing so, there are a few basic things to try:

* Implement the application with uncompressed audio instead of Opus. If it still doesn't work, then the problem isn't related to Opus
* Read the [http://www.opus-codec.org/docs/ documentation]
* Read the opus_demo.c source code to see how to use the encoder and decoder

If it still doesn't work, the best option is to ask on the [http://lists.xiph.org/mailman/listinfo/opus mailing list]

=== Forward Error correction (FEC) doesn't appear to do anything! HELP! ===

The inband FEC feature of Opus helps reduce the harm of packet loss by encoding some information about the prior packet.

In order to make use of inband FEC the decoder must delay its output by at least one frame so that it can call the decoder with the decode_fec argument on the ''next'' frame in order to reconstruct the missed frame. This works best if it's integrated with a jitter buffer.

FEC is only used by the encoder under certain conditions: the feature must be enabled via the OPUS_SET_INBAND_FEC CTL, the encoder must be told to expect loss via the OPUS_SET_PACKET_LOSS_PERC CTL, and the codec must be operated in any of the linear prediction or Hybrid modes. Frame durations of <10ms and very high bitrates will use the MDCT modes, where FEC is not available.

Even when FEC is not used, telling the encoder about the level of loss will help it make more intelligent decisions. By default the implementation assumes there is no loss.

=== What is Opus Custom? ===

Opus Custom is an '''optional''' part of the Opus standard that allows for sampling rates other than 8, 12, 16, 24, or 48 kHz and frame sizes other than multiples of 2.5 ms. Opus Custom requires additional out-of-band signalling that Opus does not normally require and disables many of Opus' coding modes. Also, because it is an optional part of the specification, using Opus Custom may lead to compatibility problems. For these reasons, its use is discouraged outside of very specific applications, e.g.:
* ultra low delay applications where synchronization with the soundcard buffer is important.
* low-power embedded applications where compatibility with others is not important.

For almost all other types of applications, Opus Custom should not be used.

=== How do I use 44.1 kHz or some other sampling rate not directly supported by Opus? ===

Tools which read or write Opus should inter-work with other sampling rate by transparently performing sample rate conversion behind the scenes. It's generally preferable to run the output at 48kHz even when you know the original input was 44.1kHz because many inexpensive audio interfaces have poor quality output for 44.1k.

In particular, software developers should not use Opus Custom for 44.1 kHz support, except in the very specific circumstances outlined above.

The opus-tools package source code contains a small, high quality, high performance, BSD licensed resampler which can be used where resampling is required.

=== I can't use malloc or much stack on my embedded platform how do I make Opus work? ===

A normal build of libopus only uses malloc/free in the _create() and _destroy() calls, so Opus is safe for realtime use so long as the codec state is pre-created.

In order to build Opus without any reference to malloc/free at all use init() calls rather than the create() calls in your application and compile with <tt>CFLAGS="-DOVERRIDE_OPUS_ALLOC -DOVERRIDE_OPUS_FREE -D'opus_alloc(x)=NULL' -D'opus_free(x)=NULL' "</tt> you will get a build which does not use malloc/free.

If libopus is built with -DNONTHREADSAFE_PSEUDOSTACK (instead of VAR_ARRAYS, or USE_ALLOCA) it will use a user provided block of heap instead of stack for many things resulting in much lower the stack usage. However this makes the resulting library non-threadsafe and is not recommend on anything except limited embedded platforms.

=== Which implementation should I use? ===

While the implementation in the latest IETF draft (and eventually RFC) of Opus is what ''defines'' the standard, it is likely not the best and most up-to-date implementation. The [http://opus-codec.org/ Opus] website was set up for the purpose of continually improving the implementation— in terms of speed, encoding quality, device compatibility, etc— while still conforming to the standard. All Opus implementations are compatible by definition.

OpusFAQ

2012-08-22T18:37:03Z

Martin.leese: /* Who created Opus? */ Typo

[[Image:Opus logo trans.png|right]]

== General Questions ==

=== What is Opus? ===

Opus is a format for compressing audio to efficiently transmit it across networks. Opus allows for music-grade high quality audio at low data rates while not delaying the signal much. Opus is distinguished from most formats for high quality audio (AAC, Vorbis, MP3) by having low delay and it is distinguished from most low delay formats (G.711, GSM, Speex) by supporting high audio quality. The Opus format itself and the reference implementation are available under liberal royalty-free licenses, making it easy to adopt, compatible with free software, and suitable for for usage as part of the basic infrastructure of the Internet.

=== Who created Opus? ===

Opus was created by combining Xiph.Org's CELT development codec and Skype's SILK codec as part of a cooperative effort in the IETF codec working group. Opus has been in development since early 2007 and will be published as an IETF proposed standard: '''[http://tools.ietf.org/html/rfc6716 RFC 6716]'''.

=== Why make Opus free? ===

On the Internet, protocol and codec standards are part of the common infrastructure everyone builds upon. Most of the value of a high quality standard is the innovation and interoperation provided by the systems built on top of it. When a few parties have monopoly rights to monetize a standard, that infrastructure stops being so common—everyone else has more reason to use their own solution instead, increasing cost and reducing efficiency. Imagine a road system where each type of car could only drive on its own manufacturer's pavement. We all benefit from living in a world where all the roads are connected. This is why Opus, unlike many codecs, is free.

=== Is the SILK part of Opus compatible with the SILK implementation shipped in Skype? ===

No. The SILK codec, as submitted by Skype to the IETF, was heavily modified as part of its integration within Opus. The modifications are significant enough that it is not possible to just write a "translator" and even sharing code between Opus and the "old SILK" would be highly non-trivial.

=== How do I use Opus / What programs use Opus? ===

=== What are the licensing requirements? ===

The reference Opus source code is released under a three-clause BSD license, which is a very permissive Open Source license. Commercial use and distribution (including in proprietary software) is permitted, provided that some basic conditions specified in the license are met.

Opus is also covered by some patents, for which royalty-free usage rights are granted, under conditions that the authors believe are compatible with most (all?) open source licenses, including the GPL (v2 and v3).

=== How does the quality of Opus compare to other codecs? ===

See the Opus [http://opus-codec.org/comparison comparison page] for more on this.

=== On what platforms does Opus run? ===

The Opus code base is written in C89 and should run on the vast majority of recent (and not so recent) CPUs. Opus has been tested and is known to run on the following (non-exhaustive list) platforms: x86, x86-64, ARM, Itanium, Blackfin, SPARC.

=== Is there a fixed-point implementation? ===

Yes, the fixed-point and floating-point decoder and encoder implementations are part of the same code base. The code defaults to float, so you need to configure with --enable-fixed-point (or defining FIXED_POINT if not using the configure script) to build the code for fixed-point.

=== Why not keep the SILK and CELT codecs separate? ===

Opus is more than just two independent codecs with a switch. It can not only run in "SILK mode" and in "CELT mode", but also in "hybrid mode" where speech frequencies up to 8 kHz are encoded with SILK while those above 8 kHz are encoded with CELT. This is what allows Opus to have such high speech quality around 32 kb/s. Another advantage of the integration is the ability to switch mode seamlessly. It is possible to change between all the modes without any "glitch" and without any out-of-band signalling.

=== Now that Opus is standardized, does it mean the development will stop? ===

Unlike most ITU-T codecs, Opus is only defined in terms of its decoder. The encoder can keep evolving as long as the bits it produces can be decoded by the reference decoder. This is what made it possible for MP3 encoders to improve far beyond the original l3enc and the dist10 reference implementation. Although it is unlikely that Opus encoders will see such spectacular evolution, we certainly hope that future encoders will become much better than the reference encoder. In fact, there is already an [http://www.opus-codec.org/development/ experimental branch] that significantly improve on the reference encoder's quality.

== Opus for Software developers ==

=== What is difference between supporting Opus and supporting Speex/G.711/MP3? ===

Opus has variable frame durations which can change on the fly, so an Opus decoder needs to be ready to accept packets with durations that are any multiple of 2.5ms up to a maximum of 120ms.

The opus encoder and decoder do not need to have matched sampling rates, bandwidths, or channel counts. Its recommended to always just decode at the highest rate the hardware supports (e.g. 48kHz stereo) so the user gets the full quality of whatever the far end is sending.

=== My application doesn't work. Can anyone help me? ===

It's possible to get help, but before doing so, there are a few basic things to try:

* Implement the application with uncompressed audio instead of Opus. If it still doesn't work, then the problem isn't related to Opus
* Read the [http://www.opus-codec.org/docs/ documentation]
* Read the opus_demo.c source code to see how to use the encoder and decoder

If it still doesn't work, the best option is to ask on the [http://lists.xiph.org/mailman/listinfo/opus mailing list]

=== Forward Error correction (FEC) doesn't appear to do anything! HELP! ===

The inband FEC feature of Opus helps reduce the harm of packet loss by encoding some information about the prior packet.

In order to make use of inband FEC the decoder must delay its output by at least one frame so that it can call the decoder with the decode_fec argument on the ''next'' frame in order to reconstruct the missed frame. This works best if it's integrated with a jitter buffer.

FEC is only used by the encoder under certain conditions: the feature must be enabled via the OPUS_SET_INBAND_FEC CTL, the encoder must be told to expect loss via the OPUS_SET_PACKET_LOSS_PERC CTL, and the codec must be operated in any of the linear prediction or Hybrid modes. Frame durations of <10ms and very high bitrates will use the MDCT modes, where FEC is not available.

Even when FEC is not used, telling the encoder about the level of loss will help it make more intelligent decisions. By default the implementation assumes there is no loss.

=== What is Opus Custom? ===

Opus Custom is an '''optional''' part of the Opus standard that allows for sampling rates other than 8, 12, 16, 24, or 48 kHz and frame sizes other than multiples of 2.5 ms. Opus Custom requires additional out-of-band signalling that Opus does not normally require and disables many of Opus' coding modes. Also, because it is an optional part of the specification, using Opus Custom may lead to compatibility problems. For these reasons, its use is discouraged outside of very specific applications, e.g.:
* ultra low delay applications where synchronization with the soundcard buffer is important.
* low-power embedded applications where compatibility with others is not important.

For almost all other types of applications, Opus Custom should not be used.

=== How do I use 44.1 kHz or some other sampling rate not directly supported by Opus? ===

Tools which read or write Opus should inter-work with other sampling rate by transparently performing sample rate conversion behind the scenes. It's generally preferable to run the output at 48kHz even when you know the original input was 44.1kHz because many inexpensive audio interfaces have poor quality output for 44.1k.

In particular, software developers should not use Opus Custom for 44.1 kHz support, except in the very specific circumstances outlined above.

The opus-tools package source code contains a small, high quality, high performance, BSD licensed resampler which can be used where resampling is required.

=== I can't use malloc or much stack on my embedded platform how do I make Opus work? ===

A normal build of libopus only uses malloc/free in the _create() and _destroy() calls, so Opus is safe for realtime use so long as the codec state is pre-created.

In order to build Opus without any reference to malloc/free at all use init() calls rather than the create() calls in your application and compile with <tt>CFLAGS="-DOVERRIDE_OPUS_ALLOC -DOVERRIDE_OPUS_FREE -D'opus_alloc(x)=NULL' -D'opus_free(x)=NULL' "</tt> you will get a build which does not use malloc/free.

If libopus is built with -DNONTHREADSAFE_PSEUDOSTACK (instead of VAR_ARRAYS, or USE_ALLOCA) it will use a user provided block of heap instead of stack for many things resulting in much lower the stack usage. However this makes the resulting library non-threadsafe and is not recommend on anything except limited embedded platforms.

=== Which implementation should I use? ===

While the implementation in the latest IETF draft (and eventually RFC) of Opus is what ''defines'' the standard, it is likely not the best and most up-to-date implementation. The [http://opus-codec.org/ Opus] website was set up for the purpose of continually improving the implementation— in terms of speed, encoding quality, device compatibility, etc— while still conforming to the standard. All Opus implementations are compatible by definition.

Ambisonics

2012-06-17T14:23:12Z

Martin.leese: /* UHJ format */ Fixed broken link

This page is part of the XiphWiki, and is aimed at people developing file
formats and associated software for Ambisonics. For an general introduction
to Ambisonics, please go to the

[[Wikipedia:Ambisonics|Wikipedia page on Ambisonics]].

'''Ambisonics''' is a surround sound system first developed in the 1970s.
Its main difference from other surround techniques is that it separates
transmission channels from speaker feeds, the speaker feeds being derived
using a decoder situated in the living room. Decoders can be implemented
in either hardware or software. Typically more speakers are used than
transmission channels, and the more speakers used then the more stable the
resulting soundfield. Speakers can be arranged in a number of configurations,
regular polygons being the most popular.

Ambisonic files can come in a number of different formats. The main one is
called B-Format, the other formats being derived from this. UHJ format is
mono- and stereo-compatible. G-Format is a set of speaker feeds, so can be
enjoyed in surround sound without the need for a decoder in the living room.

== Ambisonics and 5.1 ==

Ambisonics and conventional 5.1 surround sound are very different. 5.1 is a
set speaker feeds, the signal only being fully defined for sounds coming
from a speaker. Phantom images between speakers can be created, but the
technique to do so is left unspecified. Many 5.1 releases use pair-wise
mixing to create phantom images. This is understandable as almost all
stereo recordings are mixed using pair-wise mixing.

Pair-wise mixing is also called "pan-potting", "amplitude mixing" and
"intensity stereophony". It mixes signals into the feeds for a pair of
speakers to create the illusion that a sound is coming from a point
somewhere between the speakers. During mixing, the apparent location of
each sound is determined only by the relative amplitude of that sound in
the two speakers.

Unfortunately, pair-wise mixing works poorly when the speakers are to the
rear of the listener and not-at-all when they are to one side. You can
demonstrate this for yourself by performing
[http://members.tripod.com/martin_leese/Ambisonic/experiment.html a very simple experiment].
Pair-wise mixing did not work in the quadraphonic era and it will not work
now. Such an absolute statement can be made because the way that humans
localise sound has not changed.

Ambisonics is fundamentally different from 5.1. What is encoded in
Ambisonics is not speaker feeds, but ''direction''. When mixing in
Ambisonics, the positions of the speakers are unknown
''and are of no interest''. Further, when Ambisonics is decoded to speaker
feeds all of the speakers cooperate to localise a sound in its correct
position so, for example, when the speakers on the left push those on the
right pull. The speakers all contribute to the creation of a single
coherent soundfield.

=== Ambisonics to 5.1 ===
Converting Ambisonics to 5.1 is straightforward, and is discussed below
(see [[#G-Format|G-Format]]).

=== 5.1 to Ambisonics ===
Converting 5.1 to Ambisonics is more difficult. It is easy to make the
five speaker feeds phantom images, called "virtual speakers". (The ".1"
channel can be folded into W.) The problem with this is that even if the
Ambisonic rendering is perfect, the result will only be as good as the
original 5.1 played through ''real'' speakers. It will not be an
improvement. Nobody has yet come up with a way for Ambisonics to improve
5.1; 5.1 is simply too broken.

== B-Format ==

B-Format is a single coherent soundfield composed of a set of related
channels. The number of channels used depends on whether the soundfiled
is horizontal-only or full-sphere, and on the order. These B-Format
channels are transmission channels, not speaker feeds. Listening to
B-Format requires a decoder in your living room. Some numbers of
channels are tabulated below.

=== Channel correlation ===
Compression techniques typically make use of channel correlation to
remove redundancy from the audio data, and so improve the compression
ratio.

The correlation between B-Format channels depends on the content.
Four-channel B-Format consists of an
omni-directional component, called W, and three figure-of-eight
components pointing forward, left and up, called X, Y, Z.
([http://members.tripod.com/martin_leese/Ambisonic/Harmonic.html Pictures are available].)
Three-channel, horizontal-only B-Format simply omits the Z channel. This
means that anything in X also appears in W. Same for Y and Z. (W is
omni-directional; everything appears in W.) Also, if content comes from
Front-Left then it appears equally in X and Y. Same for content from
Front-Right, Back-Left, Back-Right; only the relative polarities change.
So there can be a lot of correlation between B-Format channels, but it is
content dependent.

One problem with B-Format is that it is big on low-frequency phase. The
phase relationships between the different B-Format channels are important
if the resulting soundfield is to correctly "gel". This may be a problem
when B-Format channels are compressed using lossy compression.

There is a file specification in use for downloadable B-Format files
called the
[http://members.tripod.com/martin_leese/Ambisonic/B-Format_file_format.html ".amb" specification].

=== Limitations of the ".amb" specification ===
The [http://members.tripod.com/martin_leese/Ambisonic/B-Format_file_format.html ".amb" specification]
for downloadable B-Format files is based on the WAVE-EX format. There are
currently over 200 pieces available in this format
[http://www.ambisonia.com for free download]. Most of these are
first-order full-sphere soundfields. (The same website also has details of
[http://www.ambisonia.com/wiki/index.php/Playback_Software ad hoc software decoders].)
Some of the limitations of the specification are:

#It is limited to 4 GByte files (2 GBytes if somebody screwed up).
#It is limited to third-order soundfields and below. While third-order looks like a lot (16 channels), there already exists a prototype mic that can record up to fourth-order (25 channels).
#No compression (particularly lossless).

The reason that the ".amb" file specification is limited to third-order
and below is because it uses the number of channels to uniquely define the
soundfield order. Unfortunately this simple and elegant scheme does not
work above third-order as ambiguities creep in. (One ambiguity is
illustrated in the table below.)

A more general file format will have to use something else, such as
''Malham notation'', or storing both the horizontal-order and
height-order. There is a one-to-one correspondence between Malham notation
and the pair of orders, and either can generate the number of channels.

==== Malham notation ====
Malham notation specifies the order of a B-Format soundfield using a
string of characters, each character being either '''f''' (for full-sphere)
or '''h''' (for horizontal). The first character in the string specifies
the type of the first-order components, the second character the type of
the second-order components, etc.

{| class="wikitable" style="text-align:center"
|
|-
!Horizontal order
!Height order
!Soundfield_type
!Malham notation
!Number of_channels
!Channels
|-
| 1|| 0||horizontal||'''h'''|| 3||WXY
|-
| 1|| 1||full-sphere||'''f'''|| 4||WXYZ
|-
| 2|| 0||horizontal||'''hh'''|| 5||WXYUV
|-
| 2|| 1||mixed-order||'''fh'''|| 6||WXYZUV
|-
| 2|| 2||full-sphere||'''ff'''|| 9||WXYZRSTUV
|-
| 3|| 0||horizontal||'''hhh'''|| 7||WXYUVPQ
|-
| 3|| 1||mixed-order||'''fhh'''|| 8||WXYZUVPQ
|-
| 3|| 2||mixed-order||'''ffh'''|| 11||WXYZRSTUVPQ
|-
| 3|| 3||full-sphere||'''fff'''|| 16||WXYZRSTUVKLMNOPQ
|-
| 4|| 0||horizontal||'''hhhh'''|| 9||extra channels unlabled
|}

=== Default channel conversions from B-Format ===
Converting a B-Format file to a mono file is straightforward. Use Mono =
W*sqrt(2).

Converting a B-Format file to a stereo file is more difficult. The "proper"
way to do this is to convert the W,X,Y channels to two-channel UHJ.
Unfortunately this requires the use of wide-band 90-degree phase shifters.
In the digital domain these are usually implemented as convolution filters.

Assuming 90-degree phase shifters are unavailable then the problem is one of
choice. Starting from B-Format, it is possible to synthesize ''any'' mic
response pointing in ''any'' direction. Hence, it is possible to synthesize
''all'' coincident stereo mic techniques. Two popular stereo techniques are
''Blumlein Mid-Side'' and ''Blumlein Crossed Pair''.

==== Blumlein Mid-Side ====
<pre>
Mid = (W*sqrt(2)) + X /*This is a cardioid response pointing forward*/
Left = Mid + Y
Right = Mid - Y
</pre>

==== Blumlein Crossed Pair ====
<pre>
Left = (X + Y)/sqrt(2) /* (Left, Right) are just the (Y, X) */
Right = (X - Y)/sqrt(2) /* responses rotated by -45 degrees */
</pre>

Which conversion to stereo is better depends on the material and how it was
recorded. A good suggestion is to not specify a ''particular'' default
channel conversion; instead, simply specify that there must be one. If one
has to be specified then Blumlein Crossed Pair is the simpler.

== UHJ format ==

B-Format is the main format for Ambisonic files. However, B-Format is
not mono- or stereo-compatible. This is why the UHJ hierarchical system
was developed. Depending on the number of channels available, the UHJ
system can carry more or less information, but at all times it is fully
mono- and stereo-compatible. Up to four channels (Left, Right, T, Q) may
be used. The T-channel can also be band-limited but, as this
"2½-channel UHJ" was only ever used for FM radio transmission, it
will not be discussed further.

To listen to UHJ files in surround requires a decoder in your living room.
Also, UHJ is restricted to first-order soundfields, either horizontal (two-
and three-channel UHJ) or full-sphere (four-channel UHJ).

Converting B-Format channels to UHJ channels, and vice versa, requires the
use of wide-band 90-degree phase shifters. In the digital domain these
are usually implemented as convolution filters. Conversion between
four-channel B-Format (W, X, Y, Z) and four-channel UHJ (Left, Right, T,
Q) can be accomplished without loss of information. The same with
three-channel to three-channel (W, X, Y) <=> (Left, Right, T). It is
possible to recover three-channel B-Format (W, X, Y) from two-channel UHJ
(Left, Right), but not without loss. It is also important for the Ambisonic
decoder to be aware that the B-Format channels were recovered from
two-channel UHJ (because of the need to apply different shelf filters).

Several hundred
[http://members.tripod.com/martin_leese/Ambisonic/uhjhtm.txt two-channel UHJ LPs and CDs]
have been released. Three- and four-channel UHJ recordings have never been
commercially released.

=== UHJ encoding and decoding equations ===

==== Encoding ====
<pre>
S = 0.9396926*W + 0.1855740*X
D = j(-0.3420201*W + 0.5098604*X) + 0.6554516*Y

Left = (S + D)/2.0
Right = (S - D)/2.0
T = j(-0.1432*W + 0.6512*X) - 0.7071*Y
Q = 0.9772*Z

where j is a +90 degree phase shift
</pre>

==== Decoding ====
For two-channel UHJ:
<pre>
S = (Left + Right)/2.0
D = (Left - Right)/2.0

W = 0.982*S + j*0.164*D
X = 0.419*S - j*0.828*D
Y = 0.763*D + j*0.385*S

where j is a +90 degree phase shift
</pre>
Note that two-channel UHJ requires the player to use different shelf filters than for B-Format.

For three- and four-channel UHJ:
<pre>
S = (Left + Right)/2.0
D = (Left - Right)/2.0

W = 0.982*S + j*0.197(0.828*D + 0.768*T)
X = 0.419*S - j(0.828*D + 0.768*T)
Y = 0.796*D - 0.676*T + j*0.187*S
Z = 1.023*Q

where j is a +90 degree phase shift
</pre>

There is a file specification for downloadable two-channel UHJ files
called the
[http://members.tripod.com/martin_leese/Ambisonic/UHJ_file_format.html ".uhj" specification], but it is not currently in use.

=== Limitations of the ".uhj" specification ===
The [http://members.tripod.com/martin_leese/Ambisonic/UHJ_file_format.html ".uhj" specification]
for downloadable two-channel UHJ files is based on the WAVE or WAVE-EX
format. A UHJ chunk is added to the file to indicate it is UHJ. As
unrecognized chunks are always skipped, use of this chunk maintains stereo
compatibility. Some of the limitations of the specification are:

#It is limited to 4 GByte files (2 GBytes if somebody screwed up).
#It is limited to two-channel UHJ files. Three- and four-channel UHJ are not accommodated.
#No compression.

The ".uhj" spcecification is only defined for two-channel UHJ to maintain
stereo compatibility. While it would be possible to add the UHJ chunk to
three- and four-channel WAVE-EX files, the recommendations from Microsoft
for playing such files is that the audio device should render the extra
channels to output ports not in use. This can happen even when the extra
channels are masked off. (Put simply, in WAVE-EX files the channel mask
does ''not'' mask channels.) Because of this, three- and four-channel
WAVE-EX files can not be made stereo compatible.

In the Xiph world, it should be possible to use default channel conversions
to ensure that three- and four-channel UHJ files remain stereo compatible.

=== Default channel conversions from UHJ ===
Converting a UHJ file to a mono file is straightforward. Use Mono =
(Left + Right) / sqrt(2).

Converting a UHJ file to a stereo file is even easier. Use Left = Left, Right = Right, and discard T and Q if present.

== G-Format ==

A G-Format file is any common multi-channel surround file containing an
Ambisonic soundfield pre-decoded to its speaker feeds. This allows
listeners who do not own an Ambisonic decoder to enjoy Ambisonics.

The sound engineer creates a set of speaker feeds for a particular number
and arrangement of speakers. This is typically four speakers arranged in
a square. Other speaker arrangements are also possible

In Ambisonics, all speakers cooperate to localise sounds in any particular
direction; there are no "surround speakers" as such. Because of this, best
results when playing G-Format recordings (and Ambisonics in general) are
obtained when the speakers are matched. The easiest way to accomplish this
is to use identical speakers. Unfortunately, many home theatre systems
include a centre-front speaker which is different from the other speakers.

An easy way to cope with this is adopted on G-Format recordings commercially
released on DVD-A by [http://www.wyastone.co.uk/nrl/dvd.html Nimbus Records].
They use four speakers in a square, the centre-front speaker being unused.

=== Recovering B-Format from G-Format ===
It is sometimes possible to recover the original B-Format channels from
the G-Format speaker feeds. The recovered B-Format channels can then be
fed to a decoder in the listener's living room, and so accommodate a
speaker arrangement different from the one used when the G-Format file
was produced. Each B-Format channel is recovered using a weighted
combination of the speaker feeds in the G-Format file. The conversion
coefficients required for the B-Format recovery depend on the particular
speaker arrangment chosen by the sound engineer. (Obviously, if a
B-Format version of the file also exists then it can be fed to the
decoder directly without the need for G-Format.)

File formats for G-Format include all multi-channel formats that contain
speaker feeds. However, these will not contain information to allow the
B-Format channels to be automatically recovered. A [http://members.tripod.com/martin_leese/Ambisonic/G-Format_chunk.html ".amg" file format]
(based on WAVE-EX) for downloadable G-Format files, which will allow
the B-Format channels to be automatically recovered, has been proposed.
Such file formats have the advantage of storing the conversion
coefficients at the time the G-Format file is created. This is the only
time the required information is readily available.

=== Default channel conversions from G-Format ===
Converting a G-Format file to a mono or stereo file is straightforward.
First, recover the B-Format channels using the conversion coefficients
contained in the file. Second, follow the advice given above for
[[#Default channel conversions from B-Format|Default channel conversions from B-Format]].

== Resources on Ambisonics ==

*There is a set of [http://en.wikipedia.org/wiki/Ambisonics Wikipedia articles on Ambisonics].
*Of particular relevance is the [http://members.tripod.com/martin_leese/Ambisonic/B-Format_file_format.html ".amb" specification] in use for downloadable B-Format files. However the ".amb" spec has some limitations which it would be useful to overcome.
*There is also the [http://members.tripod.com/martin_leese/Ambisonic/UHJ_file_format.html ".uhj" specification] for downloadable two-channel UHJ files, but it is not currently in use. The ".uhj" spec also has some limitations which it would be useful to overcome.
*[http://members.tripod.com/martin_leese/Ambisonic/ This website] has many pages on Ambisonics (including at the bottom links to other Ambisonic websites).
*[http://www.ambisonic.net/ Ambisonic.Net website] includes a detailed series of descriptive and practical articles on current and past Ambisonic techniques with links to tools, other sites and additional material.
*[http://ambisonic.info/info/ricardo.html Richard Lee's page on Ambisonics] contains articles on shelf filters and the design of Ambisonic decoders.

[[Category:Developers stuff]]

Ambisonics

2012-06-17T14:10:41Z

Martin.leese: /* Ambisonics and 5.1 */ Fixed broken link

This page is part of the XiphWiki, and is aimed at people developing file
formats and associated software for Ambisonics. For an general introduction
to Ambisonics, please go to the

[[Wikipedia:Ambisonics|Wikipedia page on Ambisonics]].

'''Ambisonics''' is a surround sound system first developed in the 1970s.
Its main difference from other surround techniques is that it separates
transmission channels from speaker feeds, the speaker feeds being derived
using a decoder situated in the living room. Decoders can be implemented
in either hardware or software. Typically more speakers are used than
transmission channels, and the more speakers used then the more stable the
resulting soundfield. Speakers can be arranged in a number of configurations,
regular polygons being the most popular.

Ambisonic files can come in a number of different formats. The main one is
called B-Format, the other formats being derived from this. UHJ format is
mono- and stereo-compatible. G-Format is a set of speaker feeds, so can be
enjoyed in surround sound without the need for a decoder in the living room.

== Ambisonics and 5.1 ==

Ambisonics and conventional 5.1 surround sound are very different. 5.1 is a
set speaker feeds, the signal only being fully defined for sounds coming
from a speaker. Phantom images between speakers can be created, but the
technique to do so is left unspecified. Many 5.1 releases use pair-wise
mixing to create phantom images. This is understandable as almost all
stereo recordings are mixed using pair-wise mixing.

Pair-wise mixing is also called "pan-potting", "amplitude mixing" and
"intensity stereophony". It mixes signals into the feeds for a pair of
speakers to create the illusion that a sound is coming from a point
somewhere between the speakers. During mixing, the apparent location of
each sound is determined only by the relative amplitude of that sound in
the two speakers.

Unfortunately, pair-wise mixing works poorly when the speakers are to the
rear of the listener and not-at-all when they are to one side. You can
demonstrate this for yourself by performing
[http://members.tripod.com/martin_leese/Ambisonic/experiment.html a very simple experiment].
Pair-wise mixing did not work in the quadraphonic era and it will not work
now. Such an absolute statement can be made because the way that humans
localise sound has not changed.

Ambisonics is fundamentally different from 5.1. What is encoded in
Ambisonics is not speaker feeds, but ''direction''. When mixing in
Ambisonics, the positions of the speakers are unknown
''and are of no interest''. Further, when Ambisonics is decoded to speaker
feeds all of the speakers cooperate to localise a sound in its correct
position so, for example, when the speakers on the left push those on the
right pull. The speakers all contribute to the creation of a single
coherent soundfield.

=== Ambisonics to 5.1 ===
Converting Ambisonics to 5.1 is straightforward, and is discussed below
(see [[#G-Format|G-Format]]).

=== 5.1 to Ambisonics ===
Converting 5.1 to Ambisonics is more difficult. It is easy to make the
five speaker feeds phantom images, called "virtual speakers". (The ".1"
channel can be folded into W.) The problem with this is that even if the
Ambisonic rendering is perfect, the result will only be as good as the
original 5.1 played through ''real'' speakers. It will not be an
improvement. Nobody has yet come up with a way for Ambisonics to improve
5.1; 5.1 is simply too broken.

== B-Format ==

B-Format is a single coherent soundfield composed of a set of related
channels. The number of channels used depends on whether the soundfiled
is horizontal-only or full-sphere, and on the order. These B-Format
channels are transmission channels, not speaker feeds. Listening to
B-Format requires a decoder in your living room. Some numbers of
channels are tabulated below.

=== Channel correlation ===
Compression techniques typically make use of channel correlation to
remove redundancy from the audio data, and so improve the compression
ratio.

The correlation between B-Format channels depends on the content.
Four-channel B-Format consists of an
omni-directional component, called W, and three figure-of-eight
components pointing forward, left and up, called X, Y, Z.
([http://members.tripod.com/martin_leese/Ambisonic/Harmonic.html Pictures are available].)
Three-channel, horizontal-only B-Format simply omits the Z channel. This
means that anything in X also appears in W. Same for Y and Z. (W is
omni-directional; everything appears in W.) Also, if content comes from
Front-Left then it appears equally in X and Y. Same for content from
Front-Right, Back-Left, Back-Right; only the relative polarities change.
So there can be a lot of correlation between B-Format channels, but it is
content dependent.

One problem with B-Format is that it is big on low-frequency phase. The
phase relationships between the different B-Format channels are important
if the resulting soundfield is to correctly "gel". This may be a problem
when B-Format channels are compressed using lossy compression.

There is a file specification in use for downloadable B-Format files
called the
[http://members.tripod.com/martin_leese/Ambisonic/B-Format_file_format.html ".amb" specification].

=== Limitations of the ".amb" specification ===
The [http://members.tripod.com/martin_leese/Ambisonic/B-Format_file_format.html ".amb" specification]
for downloadable B-Format files is based on the WAVE-EX format. There are
currently over 200 pieces available in this format
[http://www.ambisonia.com for free download]. Most of these are
first-order full-sphere soundfields. (The same website also has details of
[http://www.ambisonia.com/wiki/index.php/Playback_Software ad hoc software decoders].)
Some of the limitations of the specification are:

#It is limited to 4 GByte files (2 GBytes if somebody screwed up).
#It is limited to third-order soundfields and below. While third-order looks like a lot (16 channels), there already exists a prototype mic that can record up to fourth-order (25 channels).
#No compression (particularly lossless).

The reason that the ".amb" file specification is limited to third-order
and below is because it uses the number of channels to uniquely define the
soundfield order. Unfortunately this simple and elegant scheme does not
work above third-order as ambiguities creep in. (One ambiguity is
illustrated in the table below.)

A more general file format will have to use something else, such as
''Malham notation'', or storing both the horizontal-order and
height-order. There is a one-to-one correspondence between Malham notation
and the pair of orders, and either can generate the number of channels.

==== Malham notation ====
Malham notation specifies the order of a B-Format soundfield using a
string of characters, each character being either '''f''' (for full-sphere)
or '''h''' (for horizontal). The first character in the string specifies
the type of the first-order components, the second character the type of
the second-order components, etc.

{| class="wikitable" style="text-align:center"
|
|-
!Horizontal order
!Height order
!Soundfield_type
!Malham notation
!Number of_channels
!Channels
|-
| 1|| 0||horizontal||'''h'''|| 3||WXY
|-
| 1|| 1||full-sphere||'''f'''|| 4||WXYZ
|-
| 2|| 0||horizontal||'''hh'''|| 5||WXYUV
|-
| 2|| 1||mixed-order||'''fh'''|| 6||WXYZUV
|-
| 2|| 2||full-sphere||'''ff'''|| 9||WXYZRSTUV
|-
| 3|| 0||horizontal||'''hhh'''|| 7||WXYUVPQ
|-
| 3|| 1||mixed-order||'''fhh'''|| 8||WXYZUVPQ
|-
| 3|| 2||mixed-order||'''ffh'''|| 11||WXYZRSTUVPQ
|-
| 3|| 3||full-sphere||'''fff'''|| 16||WXYZRSTUVKLMNOPQ
|-
| 4|| 0||horizontal||'''hhhh'''|| 9||extra channels unlabled
|}

=== Default channel conversions from B-Format ===
Converting a B-Format file to a mono file is straightforward. Use Mono =
W*sqrt(2).

Converting a B-Format file to a stereo file is more difficult. The "proper"
way to do this is to convert the W,X,Y channels to two-channel UHJ.
Unfortunately this requires the use of wide-band 90-degree phase shifters.
In the digital domain these are usually implemented as convolution filters.

Assuming 90-degree phase shifters are unavailable then the problem is one of
choice. Starting from B-Format, it is possible to synthesize ''any'' mic
response pointing in ''any'' direction. Hence, it is possible to synthesize
''all'' coincident stereo mic techniques. Two popular stereo techniques are
''Blumlein Mid-Side'' and ''Blumlein Crossed Pair''.

==== Blumlein Mid-Side ====
<pre>
Mid = (W*sqrt(2)) + X /*This is a cardioid response pointing forward*/
Left = Mid + Y
Right = Mid - Y
</pre>

==== Blumlein Crossed Pair ====
<pre>
Left = (X + Y)/sqrt(2) /* (Left, Right) are just the (Y, X) */
Right = (X - Y)/sqrt(2) /* responses rotated by -45 degrees */
</pre>

Which conversion to stereo is better depends on the material and how it was
recorded. A good suggestion is to not specify a ''particular'' default
channel conversion; instead, simply specify that there must be one. If one
has to be specified then Blumlein Crossed Pair is the simpler.

== UHJ format ==

B-Format is the main format for Ambisonic files. However, B-Format is
not mono- or stereo-compatible. This is why the UHJ hierarchical system
was developed. Depending on the number of channels available, the UHJ
system can carry more or less information, but at all times it is fully
mono- and stereo-compatible. Up to four channels (Left, Right, T, Q) may
be used. The T-channel can also be band-limited but, as this
"2½-channel UHJ" was only ever used for FM radio transmission, it
will not be discussed further.

To listen to UHJ files in surround requires a decoder in your living room.
Also, UHJ is restricted to first-order soundfields, either horizontal (two-
and three-channel UHJ) or full-sphere (four-channel UHJ).

Converting B-Format channels to UHJ channels, and vice versa, requires the
use of wide-band 90-degree phase shifters. In the digital domain these
are usually implemented as convolution filters. Conversion between
four-channel B-Format (W, X, Y, Z) and four-channel UHJ (Left, Right, T,
Q) can be accomplished without loss of information. The same with
three-channel to three-channel (W, X, Y) <=> (Left, Right, T). It is
possible to recover three-channel B-Format (W, X, Y) from two-channel UHJ
(Left, Right), but not without loss. It is also important for the Ambisonic
decoder to be aware that the B-Format channels were recovered from
two-channel UHJ (because of the need to apply different shelf filters).

Several hundred
[http://members.cox.net/surround/uhjdisc/ambindex.htm two-channel UHJ LPs and CDs]
have been released. Three- and four-channel UHJ recordings have never been
commercially released.

=== UHJ encoding and decoding equations ===

==== Encoding ====
<pre>
S = 0.9396926*W + 0.1855740*X
D = j(-0.3420201*W + 0.5098604*X) + 0.6554516*Y

Left = (S + D)/2.0
Right = (S - D)/2.0
T = j(-0.1432*W + 0.6512*X) - 0.7071*Y
Q = 0.9772*Z

where j is a +90 degree phase shift
</pre>

==== Decoding ====
For two-channel UHJ:
<pre>
S = (Left + Right)/2.0
D = (Left - Right)/2.0

W = 0.982*S + j*0.164*D
X = 0.419*S - j*0.828*D
Y = 0.763*D + j*0.385*S

where j is a +90 degree phase shift
</pre>
Note that two-channel UHJ requires the player to use different shelf filters than for B-Format.

For three- and four-channel UHJ:
<pre>
S = (Left + Right)/2.0
D = (Left - Right)/2.0

W = 0.982*S + j*0.197(0.828*D + 0.768*T)
X = 0.419*S - j(0.828*D + 0.768*T)
Y = 0.796*D - 0.676*T + j*0.187*S
Z = 1.023*Q

where j is a +90 degree phase shift
</pre>

There is a file specification for downloadable two-channel UHJ files
called the
[http://members.tripod.com/martin_leese/Ambisonic/UHJ_file_format.html ".uhj" specification], but it is not currently in use.

=== Limitations of the ".uhj" specification ===
The [http://members.tripod.com/martin_leese/Ambisonic/UHJ_file_format.html ".uhj" specification]
for downloadable two-channel UHJ files is based on the WAVE or WAVE-EX
format. A UHJ chunk is added to the file to indicate it is UHJ. As
unrecognized chunks are always skipped, use of this chunk maintains stereo
compatibility. Some of the limitations of the specification are:

#It is limited to 4 GByte files (2 GBytes if somebody screwed up).
#It is limited to two-channel UHJ files. Three- and four-channel UHJ are not accommodated.
#No compression.

The ".uhj" spcecification is only defined for two-channel UHJ to maintain
stereo compatibility. While it would be possible to add the UHJ chunk to
three- and four-channel WAVE-EX files, the recommendations from Microsoft
for playing such files is that the audio device should render the extra
channels to output ports not in use. This can happen even when the extra
channels are masked off. (Put simply, in WAVE-EX files the channel mask
does ''not'' mask channels.) Because of this, three- and four-channel
WAVE-EX files can not be made stereo compatible.

In the Xiph world, it should be possible to use default channel conversions
to ensure that three- and four-channel UHJ files remain stereo compatible.

=== Default channel conversions from UHJ ===
Converting a UHJ file to a mono file is straightforward. Use Mono =
(Left + Right) / sqrt(2).

Converting a UHJ file to a stereo file is even easier. Use Left = Left, Right = Right, and discard T and Q if present.

== G-Format ==

A G-Format file is any common multi-channel surround file containing an
Ambisonic soundfield pre-decoded to its speaker feeds. This allows
listeners who do not own an Ambisonic decoder to enjoy Ambisonics.

The sound engineer creates a set of speaker feeds for a particular number
and arrangement of speakers. This is typically four speakers arranged in
a square. Other speaker arrangements are also possible

In Ambisonics, all speakers cooperate to localise sounds in any particular
direction; there are no "surround speakers" as such. Because of this, best
results when playing G-Format recordings (and Ambisonics in general) are
obtained when the speakers are matched. The easiest way to accomplish this
is to use identical speakers. Unfortunately, many home theatre systems
include a centre-front speaker which is different from the other speakers.

An easy way to cope with this is adopted on G-Format recordings commercially
released on DVD-A by [http://www.wyastone.co.uk/nrl/dvd.html Nimbus Records].
They use four speakers in a square, the centre-front speaker being unused.

=== Recovering B-Format from G-Format ===
It is sometimes possible to recover the original B-Format channels from
the G-Format speaker feeds. The recovered B-Format channels can then be
fed to a decoder in the listener's living room, and so accommodate a
speaker arrangement different from the one used when the G-Format file
was produced. Each B-Format channel is recovered using a weighted
combination of the speaker feeds in the G-Format file. The conversion
coefficients required for the B-Format recovery depend on the particular
speaker arrangment chosen by the sound engineer. (Obviously, if a
B-Format version of the file also exists then it can be fed to the
decoder directly without the need for G-Format.)

File formats for G-Format include all multi-channel formats that contain
speaker feeds. However, these will not contain information to allow the
B-Format channels to be automatically recovered. A [http://members.tripod.com/martin_leese/Ambisonic/G-Format_chunk.html ".amg" file format]
(based on WAVE-EX) for downloadable G-Format files, which will allow
the B-Format channels to be automatically recovered, has been proposed.
Such file formats have the advantage of storing the conversion
coefficients at the time the G-Format file is created. This is the only
time the required information is readily available.

=== Default channel conversions from G-Format ===
Converting a G-Format file to a mono or stereo file is straightforward.
First, recover the B-Format channels using the conversion coefficients
contained in the file. Second, follow the advice given above for
[[#Default channel conversions from B-Format|Default channel conversions from B-Format]].

== Resources on Ambisonics ==

*There is a set of [http://en.wikipedia.org/wiki/Ambisonics Wikipedia articles on Ambisonics].
*Of particular relevance is the [http://members.tripod.com/martin_leese/Ambisonic/B-Format_file_format.html ".amb" specification] in use for downloadable B-Format files. However the ".amb" spec has some limitations which it would be useful to overcome.
*There is also the [http://members.tripod.com/martin_leese/Ambisonic/UHJ_file_format.html ".uhj" specification] for downloadable two-channel UHJ files, but it is not currently in use. The ".uhj" spec also has some limitations which it would be useful to overcome.
*[http://members.tripod.com/martin_leese/Ambisonic/ This website] has many pages on Ambisonics (including at the bottom links to other Ambisonic websites).
*[http://www.ambisonic.net/ Ambisonic.Net website] includes a detailed series of descriptive and practical articles on current and past Ambisonic techniques with links to tools, other sites and additional material.
*[http://ambisonic.info/info/ricardo.html Richard Lee's page on Ambisonics] contains articles on shelf filters and the design of Ambisonic decoders.

[[Category:Developers stuff]]

XMLEmbedding

2012-06-12T17:40:44Z

Martin.leese: Made clear spec is for both XML files and XML streams

{{draft}}
Schemes such as [[M3F]] require an embedding in physical Ogg streams. This page is for development of a specification for embedding XML files and XML streams in Ogg. The final version will probably look like the CMML mapping.

==Current plans==
(taken from mailing list discussions)

===Magic number?===

Should we have a magic number for this? By convention the beginning of stream packet for codecs in Ogg identifies the packet, Strictly speaking we will have a magic number regardless, but should it be:

* '<?xml' the opening of the XML declaration. In this instance the demuxer would pass this upwards to an XML parser which would derive from the rest of the bos packet what to do with it.

* Some other sequence before the XML starts, identifying the particular stream type, probably with a version number which will imply the contents to be some form of XML. CMML does this. This may avoid the almost inevitable problem of some implementor assuming '<?xml' is always metadata, it may also reduce the difficulty of writing a demuxer. Demuxers could still peek ahead and try to look for an xml namespace it recognizes.

===Division into packets===

The raw XML should ideally be broken into packets in a way that the loss of some packets, while destroying information, does not result in an invalid stream. Generally this means:

* The bos packet should consist of any initial processing directives, namespace declarations, and the root tag if there is one.
* Subsequent packets should be valid xml stanzas, similar to the [http://xmpp.org/ XMPP] definition, which concatenated are also valid xml.
* The eos packet can be empty. If there was a root tag in the bos packet, it should be closed here.

Parsers should close all open tags on encountering eos to handle truncated stream conditions. Encountering eos here means either a after processing a packet marked with the eos flag, having finished on an Ogg page with the eos flag set, or a virtual eos, implied by encountering bos flags for a new chain segment.

===Granulepos mapping===

c.f. Silvia Pfeiffer on [http://lists.xiph.org/pipermail/ogg-dev/2007-September/000570.html ogg-dev]:
<blockquote>I suggest using the solution that CMML has come to use.

The XML file is essentially the same as an unencapsulated physical bitstream.

Then there is a mapping into a logical bitstream, where some of the
default information - in particular the XML header - are split off and
put into the bos packet - nothing really needs to go into the eos
packet. There's also a magic number and a version number.

Also, use the granulepos scheme that we defined for CMML pages- you're
going to make your lives easier.</blockquote>

That is, use a split granulepos scheme like keyframe codecs to indicate the offset to the previous packet.
Whether this is appropriate for a given XML steam will depend on its application. Metadata that applies
to the whole stream should just be included at the beginning, like OggSkeleton, and the granulepos can just
all be zero. Time-based data, like a slideshow or 'currently playing' for radio streams, should be muxed
throughout the stream.

Given that the CMML mapping would be sensible should we simply hijack
CMML for this use (i.e. just put the metadata XML in a CMML stream?
Arguments against this: it means stream parsing is needed to find out
whether the CMML stream contains metadata too and possibly complicates
CMML handling. If not hijacking CMML it might be worth having a flag
indicating whether the stream is continuous or secondary header only.

===ID===
It seems reasonable to use the fishbone message fields in [[Ogg Skeleton]] to supply an ID to be associated
with each logical stream (via an "id:" message header field). The other side of this problem is how
these should be addressed. The physical bitstream itself shouldn't need one, but do we worry about
chained/concatenated streams?

The Skeleton section of the [http://annodex.net/TR/draft-pfeiffer-annodex-02.html#anchor8 Annodex bitstream format]
specifies that mandatory header fields MUST be US-ASCII encoded, but allows UTF-8 for other message fields. This
does not appear to be a problem for an ID field. [http://www.ietf.org/rfc/rfc2822.txt RFC2822] limits message header
fields to 998 bytes (excluding CRLF) and spaces are not normally permitted in IDs, so IDs would be limited to 994
bytes long.

===Mime type===
For use in Skeleton. [[MIME Types and File Extensions]] gives 'text/cmml' for 'CMML without container', if that
can be used by Skeleton to describe packetized CMML in Ogg then there's no issue here; 'text/xml' or whatever
is appropriate could be used.

==Test Files==
It is a barrier to the widespread introduction of any metadata format that the [http://www.xiph.org/vorbis/doc/Vorbis_I_spec.html Vorbis I spec] only requires players to support an unaccompanied [[Vorbis]] stream; many [[Ogg]] [[Vorbis]] players will refuse to play augmented streams, especially if the content is not recognised (although many recent players do succeed). As a prelude to development of an [[Ogg]] metadata format it will be necessary to encourage developers to introduce more flexible [[Ogg]] filters.

One of the intentions of the current work on [[MIME Types and File Extensions]] is to superseede the Vorbis I spec allowing all types of metadata to be included and encouraging program writers to ignore unrecognised content in these files. The metadata embedded Ogg files below are therefore '.oga' served as audio/x-ogg. '''You may want to use your browser's''' ''save as'' '''function if you have trouble opening the links.'''

To help with testing the following files are available, based on a speculative (and very basic) metadata format. In each case the derivative files are under the same license as the original. Two sets are provided to allow chained stream testing. On some players the seek tests produce an annoying clicking—if you like the music get the originals. Please notice that filenames are mixed case
and add a note in discussion if you find a broken link.

Original (Vorbis I): [http://music.ibiblio.org/pub/multimedia/pandora/vorbis/contrib/Debbie_Hu/Bach-Busoni_Nun_freut_euch_3.ogg Bach - Nun freut euch lieben Christen] performed by Debbie Hu, from [http://music.ibiblio.org/pub/multimedia/pandora/mp3/Read.html Pandora Records] and available under the [http://www.eff.org/IP/Open_licenses/eff_oal.php EFF OAL].
* The [http://www.srcf.ucam.org/~ibm21/Bach-Busoni_Nun_freut_euch_3.rdf.oga Ogg-Vorbis-XML version]
* The XML/RDF description as a [http://www.srcf.ucam.org/~ibm21/Bach-Busoni_Nun_freut_euch_3.xml separate document]
* With the XML page [http://www.srcf.ucam.org/~ibm21/Bach-Busoni_Nun_freut_euch_3.multi.oga repeated after every fifth Vorbis page]. (This is not a suggested way to add meta data, just a way of testing how players handle seeking in the presence of an unknown stream.)
* With the XML page repeated after every fifth Vorbis page and the [http://www.srcf.ucam.org/~ibm21/Bach-Busoni_Nun_freut_euch_3.end.oga stream ending on a meta data page] (breaks simpler track-length strategies, again not a suggested format for metadata)

Original (Vorbis I): [http://ccmixter.org/media/files/disharmonic/2958/ On The Moon (Trip Hop mix)] by [http://ccmixter.org/media/people/disharmonic/ Disharmonic], from [http://ccmixter.org/ ccMixter] and available under the Creative Commons [http://creativecommons.org/licenses/by/2.5/ Attribution 2.5] license.
* The XML/RDF description as a [http://www.srcf.ucam.org/~ibm21/disharmonic_-_On_The_Moon_(Trip_Hop_mix).xml separate document]
* With the XML page [http://www.srcf.ucam.org/~ibm21/disharmonic_-_On_The_Moon_(Trip_Hop_mix).multi.oga repeated after every fifth Vorbis page].
* With the XML page repeated after every fifth Vorbis page and the [http://www.srcf.ucam.org/~ibm21/disharmonic_-_On_The_Moon_(Trip_Hop_mix).end.oga stream ending on a meta data page]

VorbisComment

2012-06-09T15:55:41Z

Martin.leese: /* ISO proposal */ Added ISO number

VorbisComment is a base-level [[Metadata]] format initially created for use with Ogg [[Vorbis]]. It has since been adopted in the specifications of
[[Ogg]] encapsulations for other Xiph.Org codecs including [[Theora]], [[Speex]] and [[FLAC]].

The use case for VorbisComment is given as:
<blockquote>
... 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.[http://xiph.org/vorbis/doc/v-comment.html]
</blockquote>

VorbisComments are typically used to provide basic information like the title and copyright holder of a work.
As such the scope is similar to that of ID3 tags used with MP3 files.
VorbisComment is widely supported on [[VorbisHardware|portable Ogg Vorbis players]] as well as streaming, editing and playback software.

Although the syntax of VorbisComment is well-specified, various conventions exist for the field names in use.
The goal for this page is to codify best practices and collect proposals for standardization of VorbisComment field names.

VorbisComments are typically encoded as the second packet in a codec stream. When VorbisComments are included in the first (ie. Theora) stream of an Ogg Theora file, they are assumed to cover all streams in the multiplexed group. [http://lists.xiph.org/pipermail/vorbis-dev/2008-December/019676.html]

VorbisComment is the simplest and most widely-supported mechanism for storing metadata with Xiph.Org codecs. For other existing and proposed mechanisms, see [[Metadata]].

== Recommended field names ==

The current [http://xiph.org/vorbis/doc/v-comment.html VorbisComment recommendation] contains a recommended set
of field names for comments.

== Proposed field names ==

Some proposals for extra field names:

* [http://age.hobba.nl/audio/mirroredpages/ogg-tagging.html Ogg Vorbis Comment Field Recommendations]
* [http://gophernet.org/articles/vorbiscomment/ Proposals for extending Ogg Vorbis comments]
* [[Field names]]
* [[Chapter Extension]]

Comments are intended to be free-form, but for the purposes of interoperability, it is helpful to define tag sets for particular applications, and provide some guidelines for machine parsing. Note that some field names have to be non-free-form to achieve machine parsing.

=== Cover art ===

==== METADATA_BLOCK_PICTURE ====
The [http://flac.sourceforge.net/format.html#metadata_block_picture binary FLAC picture structure] is base64 encoded and placed within a VorbisComment with the tag name "METADATA_BLOCK_PICTURE". This is the preferred and recommended way of embedding cover art within VorbisComments. It has the following benefits:

* Easy to use for developers since the identical (or similar) structure is also used by FLAC and MP3.
* The cover art can either be linked or embedded within the stream.
* Common picture file formats are supported (jpg and png).
* A description may be included and the picture type (front cover, back cover...) and image mime type are provided.
* Base64 encoded data is invariant under UTF-8 and a valid UTF-8 string, so obeys the rules for comment data.

Implementations interpreting or writing picture blocks should note the following details:

===== General encoding/decoding =====
* Failure to decode a picture block should not prevent playback of the file (failure to deal with the particularly large packet required by the comment header is a separate problem with the player implementation).
* Base64 encoding is used as in section 4 of [http://www.faqs.org/rfcs/rfc4648.html RFC4648]. We note that line feeds are not allowed and padding characters ('=') are required.
* Applications adding picture blocks should inform users that some applications or hardware may not support them and should provide a method to remove the blocks (this is expected to be trivial for applications capable of adding them).

===== Block handling =====
* The unencoded format is that of the [http://flac.sourceforge.net/format.html#metadata_block_picture FLAC picture block]. The fields are stored in big endian order as in FLAC, picture data is stored according to the relevant standard.
* Picture data should be stored in PNG or JPEG formats or linked separately. It is recommended readers support both PNG and JPEG
* Allowed values for the MIME string are "image/", "image/png", "image/jpeg" and "-->" (the link indicator) and "" (length 0). An empty MIME string indicates type "image/"
* Fields present in the ID3V2.4.0 [http://www.id3.org/id3v2.4.0-frames#line-1085 Attached Picture Frame] (APIC Frame) take the same interpretation as in the ID3V2.4.0 format with the following exceptions (following the FLAC format):
** The description field is UTF-8 (encoded without ID3V2's initial 'encoding byte')
** String fields are not null terminated: their preceding length fields are used instead.

===== Linked images =====
Support for linked images is optional for applications handling picture blocks. When a linked picture is indicated the following rules are observed:
* The picture data is a complete URL indicating the picture to be used, relative URLs are allowed (note relative URLs do not start with a protocol specifier and are retrieved with the same protocol as the file being processed).
* Links are ISO-8859-1 encoded
* Applications MAY retrieve linked images via the file:// protocol.
* Applications MUST obtain user approval if they wish to retrieve images via remote protocols.
* Link targets may become unavailable: applications supporting linked images SHOULD recover gracefully from this and MAY report the absence to the user.
* The type of the linked file is not restricted to JPEG and JFIF and applications MAY support other formats
* If the application does not support linked images, the target is unavailable, not permitted or an unknown format the picture block should be skipped.
* Applications may make links available to users, this is of particular use when links are unsupported or of unsupported type

===== Image dimension fields =====
* The height, width, colour depth and 'number of colours' fields are for purely informational purposes. Applications MUST NOT use them for decoding purposes, but MAY display them to the user and MAY use them to make a decision whether to skip the block (for example if selecting the most appropriate among multiple blocks).
* Applications writing picture blocks MUST set these fields correctly OR set them all to zero.

===== Multiple blocks =====
* Multiple image blocks MAY be included as separate METADATA_BLOCK_PICTURE comments.
* There may only be one each of picture type (APIC type) 1 and 2 in a Vorbis stream.
* Block order is significant for some types and applications should preserve the comment order when reading or writing VorbisComment headers. The block order may be used to determine the order pictures are presented to the user.

===== Playback tests =====
Embedding a picture into the file might break playback of existing players (especially hardware players, software players could be updated easily). A workaround would be to link the picture within the tag. Furthermore users should become informed in some way that embedding a picture COULD cause problems (as stated above).

In order to test if there are playback problems, there are test files available [http://www.audioranger.com/coverart_mk.ogg here] and [http://www.audioranger.com/coverart_im.ogg here]. You're invited to download one of these test files (or both), test playback on your software and hardware players, and report the results here on the wiki.

'''Tested software players'''
* Audacious 1.5.1: no problem
* foobar2000: no problems
* Gnome: built-in preview playback: no problem
* MediaMonkey: no problems
* Media Player Classic (unicode build) 6.4.9.1: no problem
* RoarAudio: no problems (server and client side)
* Rythmbox 0.11.6: no problem
* Totem 2.24.3: no problem
* VLC 0.9.4/0.9.6: doesn't play
** Patch send to VLC to fix this - should get in 1.0.0
* WinAmp: no problems
* Windows Media Player 11: no problem
* XMPlay 3.4.2: no problem
* Nero ShowTime: no problem
* Songbird 1.8.0: no problem, able to show and edit embedded pictures

'''Tested hardware players'''
* Logitech Squeezebox: Supported as of January 2009 (server version 7.3.3)
* Sandisk Sansa Fuze (Firmware 01.01.22): Hangs up when trying to playback the demo file - had to reset the player
** Note: The "Fuze" can play ogg vorbis files which have embedded pictures from "Easytag"
* Cowon iAudio U3 (Firmware 1.29, 4 GB): works
* Cowon D2: no problem (latest Firmware: 2.59, 8GB Version)
* iRiver E100: no problem (latest Firmware: 1.16 G_U, 8GB Version)
* Samsung YP-R1: no problem (latest Firmware: 3.07, 16GB Version)

'''Tested tag editors'''
* Easytag 2.1.6: can open the file to edit the normal tag fields
* MP3Tag 2.42e: can open the file to edit the normal tag fields
* MP3Tag 2.47b: is able to show and edit embedded pictures

'''Tested other software'''
* Total Recorder: capable to work with artwork according to the specification.

==== Unofficial COVERART field (deprecated) ====
There also exists an unofficial, not well supported comment field named "COVERART". It includes a base64-encoded string of the binary picture data (usually a JPEG file, but this could be a different file format too). The disadvantages are that
* no additional information like a description about the cover art or its type (front cover, back cover etc.) is provided,
* the cover art can't be linked
* the base64 string is displayed within many tag editors as plain text because of their missing support for this "COVERART" field
* it may breaks the playback on hardware players because of a large VorbisComment header
The unofficial "COVERART" field is supported for example by such software as AudioShell (http://www.softpointer.com/AudioShell.htm) - read/write, and Total Recorder (http://www.totalrecorder.com/)- only read.

===== Conversion to METADATA_BLOCK_PICTURE =====
Old "COVERART" tags should be converted to the new METADATA_BLOCK_PICTURE tag (see above for its specification). This conversion is straightforward and is suggested to be done the following way:

* Decode the COVERART tag. A program MAY check the signature of the embedded picture in order to determine whether it is an allowed type. Lossless conversion from disallowed types to allowed types MAY be carried out.
* Fill out the FLAC block with the binary picture data. If the MIME type of the picture is unknown or can't be determined, the MIME type "image/" MAY be used instead. Supplying image dimensions, color depth etc. is optional (see specification above).
* In the absence of other information the picture type 'Other' should be used. Applications may want to allow users to select a default type or specify the type to use.
* Encode the new picture block, remove the COVERART tag from the comments and add the METADATA_BLOCK_PICTURE entry.
* If multiple tags are being converted the order of the METADATA_BLOCK_PICTURE tags should be the same as that of the COVERART tags they are replacing.

=== Chapter Extension ===

These are used to include navigation points, for example:
<pre>
CHAPTER001=00:00:00.000-->00:05:00.000
CHAPTER001NAME=Chapter 1
CHAPTER001URL=http://...
</pre>

See the [[Chapter Extension]] page for more details.

=== Date and time ===

The goal is to specify '''one''' standard format for describing date and/or time.

==== ISO proposal ====
The date format for any field describing a date must follow the ISO 8601 standard: YYYY-MM-DD, shortened to just YYYY-MM or simply YYYY.

We have been recommending this usage with the DATE tag for some time. It is proposed that the spec be amended to include this information for machinability.

The time format for any field '''except''' track duration must be specified with leading T and ending with a time zone. Schemas with and without dates:
<pre>
YYYY-MM-DDTHH:MM:SS+TS
</pre>
<pre>
THH:MM+TZ
</pre>

=== ENCODER ===

The goal is to attribute encoder software. This value can be used in the future to determine which files can be improved by being re encoded with a newer version.

:'''Comment''': What is lacking from the vendor string present in the spec from the start? All libvorbis and encoder tunings I'm aware of have recorded the encoder version here.

Rationale for not using the vendor string:
* The vendor string is usually used to store the name and version of the underlying codec library
* The idea of ENCODER is to store the name of the user-visible application, for example <tt>ffmpeg2theora</tt>.
* It can be useful for debugging to store the name and version of the calling application.
* The libvorbis API does not let applications override the vendor string.

==== Proposal: Inclusion of URL in ENCODER value ====
The encoder field name must be a unique URL providing both encoder software name and version. If no unique URL address is available were both name and version is available; then the version number can be specified by separating with a space character. For example:

<nowiki>ENCODER=http://flac.sourceforge.net/ 1.2.1</nowiki>

* Note that ffmpeg2theora uses ENCODER, but does not include a url. ''Added by Rillian on September 17, 2007''

==== Proposal: ENCODED_BY ====

I've also seen ENCODED_BY. ''Added by Rillian on September 17, 2007''
: ENCODED_BY is usually the person who did the encoding. This should not be part of the recommendation due to legal problems around deliberate and accidental distribution to third parties. Basically the name of the encoder should not be included to protect encoders from their own egos and possible legal prosecution. ''Added by Aleksandersen on September 20, 2007''

=== Improving license data ===

The goal is to provide a method for proclaiming license and copyright information (basically clarifying ‘distribution rights (if any) and ownership’).

The [http://xiph.org/vorbis/doc/v-comment.html specification document] describes LICENSE and COPYRIGHT fields. But is not clear enough about whether these should be machine-readable.

We should consider working together with Creative Commons to have complementary and interlinked information on the Creative Commons and Xiph wikis. Refer to the [http://wiki.creativecommons.org/Ogg Ogg page] in the Creative Commons wiki.

==== New RIGHTS field name proposal ====
One proposal is to replace the COPYRIGHT and LICENSE field names with RIGHTS. RIGHTS must be a human-readable copyright statement. Basic example:

<nowiki>RIGHTS=Copyright © Recording Company Inc. All distribution rights reserved.</nowiki>

But this is not machine-readable. Adding two complementary field names should do the trick: RIGHTS-DATE, describing the date of copyright; and RIGHTS-URI, providing a method for linking to a license. Software agents can assume that multiple songs uses the sameURIs, such as in the case for Creative Commons. Full example:

<nowiki>RIGHTS=Copyright © 2019 Recording Company Inc. All distribution rights reserved.</nowiki> 
<nowiki>RIGHTS-DATE=2019-04</nowiki> 
<nowiki>RIGHTS-URI=http://somewhere.com/license.xhtml</nowiki>

Software such as for multimedia management and playback are encouraged to display the RIGHTS statement as a linked phrase using RIGHTS-URI.

RIGHTS-DATE does not need to be displayed as it is required in the human readable version by international copyright agreements. RIGHTS-DATE can be used to determine when a copyrighted work falls under the public domain and related matters. (''The Beatles''' copyright on their original studio recordings (not the remixes) are soon expiering. So mechanisms such as the RIGHTS-DATE are indeed required in music management and filesharing software!)

To remain machine-readable it would be required to have at most one instance of each RIGHTS field name. All fields would of course remain optional.

The ''Dublin Core Metadata Initiative'' recommends the use of ‘rights’ to describe license and copyright matters. The web feed format Atom 1.0 has implemented a rights element in their specification.

:'''Comment''': The triplet RIGHTS, RIGHTS-DATE, RIGHTS-URI is an example of structured metadata. VorbisComments are inherently unstructured, and this should be respected. Structured metadata belongs in a different stream, such as XML (using [[Metadata#XMLEmbedding|XMLEmbedding]]).

==== Improving existing fields proposal ====
Similar to the DATE tag above, we have generally recommended that a URL uniquely identifying the license be included in the LICENSE field to allow machine identification of the license. This is in agreement with the proposal in the Creative Commons wiki. Since the COPYRIGHT field is a human-readable statement of the copyright, like the proposed RIGHTS tag above, some people include a license url there. Therefore if a url can't be found in a LICENSE tag if any, applications should use one from the COPYRIGHT tag, if any. Contact information for verification, attribution, relicensing, etc. can be obtained from the COPYRIGHT field, but Creative Commons also recommend a separate CONTACT tag for this information. This is reasonable, so we propose it be included.

=== Geo Location fields ===

The existing LOCATION field is meant to carry a human readable location for the recording/creation of the media file.

Having geographical coordinates according to [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84] can be useful as well, especially in a form that can be machine parsed. The agreed format is similar to this [http://en.wikipedia.org/wiki/Geo_(microformat) geo microformat]:

GEO_LOCATION= ''latitude'' ; ''longitude'' [; ''elevation'' ]

where each value is a fixed point decimal number formatted in the C locale with a period (.) for the radix. Values are separated with a ';' and white space is not significant. The elevation is optional.

''latitude'' is the geo latitude location of where the media has been recorded or produced in decimal degrees according to WGS84 (zero at the equator, negative values for southern latitudes) (C double).

''longitude'' is the geo longitude location of where the media has been recorded or produced in decimal degrees according to WGS84 (zero at the prime meridian in Greenwich/UK, negative values for western longitudes). (C double).

''elevation'' is the geo elevation of where the media has been recorded or produced in meters according to WGS84 (zero is average sea level) (C double).

=== Replay Gain ===

The REPLAYGAIN_* fields implement the Replay Gain proposal for storing a track relative volume adjustment, which can be used to "fix" quiet or loud sounding Vorbis or FLAC streams. The set of tags is intended to be machine parsed, and has the following form:
<pre>
REPLAYGAIN_TRACK_GAIN=-7.03 dB
REPLAYGAIN_TRACK_PEAK=1.21822226
REPLAYGAIN_ALBUM_GAIN=-6.37 dB
REPLAYGAIN_ALBUM_PEAK=1.21822226
</pre>

See http://www.replaygain.org/ for detailed information about Replay Gain and how the different values are calculated.

=== Tantalos resource ID ===
Tantalos is a protocol to auto locate and access content in a network scope (normally 'LAN' but can also be bigger like 'company network'). It uses UUIDs to identify resources. There are two groups of those UUIDs: IDs generated using the meta data of the track and IDs generated in some other way (for example random IDs, see UUID specs). The later group may need to be passed with the track. The VCLT Playlist format (see below) uses 'HASH={UUID}id...' with hex-dash format for this (HASH={UUID}e278173d-4d6d-4c66-95ec-4ec85eedc7d1).
--[[User:Ph3-der-loewe|Ph3-der-loewe]] 02:05, 13 December 2011 (PST)

== Other (non-proposed field names) ==
=== VCLT playlist format ===
The VCLT playlist format uses some ''keys'' which look like VorbisComments but they aren't nor they are proposed to become (expect for HASH). This includes the keys STREAMURL, FILENAME, FILEURL, LENGTH, HASH (see above for this one), SIGNALINFO, AUDIOINFO and OFFSET. You can find more infos about those at [https://bts.keep-cool.org/wiki/Specs/VCLT https://bts.keep-cool.org/wiki/Specs/VCLT].

== Implementations ==

* [http://sbooth.org/importers/ OggImporter] – imports Ogg Vorbis and Ogg FLAC files to Spotlight.
* vorbiscomment – a commandline tool, part of [[VorbisTools]].
* [http://www.xiph.org/oggz/ oggz-comment] – a commandline tool, part of [[Oggz]] tool. It can add comments to multitrack and video files.

VorbisComment

2012-06-08T16:51:08Z

Martin.leese: Added Chapter Extension

VorbisComment is a base-level [[Metadata]] format initially created for use with Ogg [[Vorbis]]. It has since been adopted in the specifications of
[[Ogg]] encapsulations for other Xiph.Org codecs including [[Theora]], [[Speex]] and [[FLAC]].

The use case for VorbisComment is given as:
<blockquote>
... 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.[http://xiph.org/vorbis/doc/v-comment.html]
</blockquote>

VorbisComments are typically used to provide basic information like the title and copyright holder of a work.
As such the scope is similar to that of ID3 tags used with MP3 files.
VorbisComment is widely supported on [[VorbisHardware|portable Ogg Vorbis players]] as well as streaming, editing and playback software.

Although the syntax of VorbisComment is well-specified, various conventions exist for the field names in use.
The goal for this page is to codify best practices and collect proposals for standardization of VorbisComment field names.

VorbisComments are typically encoded as the second packet in a codec stream. When VorbisComments are included in the first (ie. Theora) stream of an Ogg Theora file, they are assumed to cover all streams in the multiplexed group. [http://lists.xiph.org/pipermail/vorbis-dev/2008-December/019676.html]

VorbisComment is the simplest and most widely-supported mechanism for storing metadata with Xiph.Org codecs. For other existing and proposed mechanisms, see [[Metadata]].

== Recommended field names ==

The current [http://xiph.org/vorbis/doc/v-comment.html VorbisComment recommendation] contains a recommended set
of field names for comments.

== Proposed field names ==

Some proposals for extra field names:

* [http://age.hobba.nl/audio/mirroredpages/ogg-tagging.html Ogg Vorbis Comment Field Recommendations]
* [http://gophernet.org/articles/vorbiscomment/ Proposals for extending Ogg Vorbis comments]
* [[Field names]]
* [[Chapter Extension]]

Comments are intended to be free-form, but for the purposes of interoperability, it is helpful to define tag sets for particular applications, and provide some guidelines for machine parsing. Note that some field names have to be non-free-form to achieve machine parsing.

=== Cover art ===

==== METADATA_BLOCK_PICTURE ====
The [http://flac.sourceforge.net/format.html#metadata_block_picture binary FLAC picture structure] is base64 encoded and placed within a VorbisComment with the tag name "METADATA_BLOCK_PICTURE". This is the preferred and recommended way of embedding cover art within VorbisComments. It has the following benefits:

* Easy to use for developers since the identical (or similar) structure is also used by FLAC and MP3.
* The cover art can either be linked or embedded within the stream.
* Common picture file formats are supported (jpg and png).
* A description may be included and the picture type (front cover, back cover...) and image mime type are provided.
* Base64 encoded data is invariant under UTF-8 and a valid UTF-8 string, so obeys the rules for comment data.

Implementations interpreting or writing picture blocks should note the following details:

===== General encoding/decoding =====
* Failure to decode a picture block should not prevent playback of the file (failure to deal with the particularly large packet required by the comment header is a separate problem with the player implementation).
* Base64 encoding is used as in section 4 of [http://www.faqs.org/rfcs/rfc4648.html RFC4648]. We note that line feeds are not allowed and padding characters ('=') are required.
* Applications adding picture blocks should inform users that some applications or hardware may not support them and should provide a method to remove the blocks (this is expected to be trivial for applications capable of adding them).

===== Block handling =====
* The unencoded format is that of the [http://flac.sourceforge.net/format.html#metadata_block_picture FLAC picture block]. The fields are stored in big endian order as in FLAC, picture data is stored according to the relevant standard.
* Picture data should be stored in PNG or JPEG formats or linked separately. It is recommended readers support both PNG and JPEG
* Allowed values for the MIME string are "image/", "image/png", "image/jpeg" and "-->" (the link indicator) and "" (length 0). An empty MIME string indicates type "image/"
* Fields present in the ID3V2.4.0 [http://www.id3.org/id3v2.4.0-frames#line-1085 Attached Picture Frame] (APIC Frame) take the same interpretation as in the ID3V2.4.0 format with the following exceptions (following the FLAC format):
** The description field is UTF-8 (encoded without ID3V2's initial 'encoding byte')
** String fields are not null terminated: their preceding length fields are used instead.

===== Linked images =====
Support for linked images is optional for applications handling picture blocks. When a linked picture is indicated the following rules are observed:
* The picture data is a complete URL indicating the picture to be used, relative URLs are allowed (note relative URLs do not start with a protocol specifier and are retrieved with the same protocol as the file being processed).
* Links are ISO-8859-1 encoded
* Applications MAY retrieve linked images via the file:// protocol.
* Applications MUST obtain user approval if they wish to retrieve images via remote protocols.
* Link targets may become unavailable: applications supporting linked images SHOULD recover gracefully from this and MAY report the absence to the user.
* The type of the linked file is not restricted to JPEG and JFIF and applications MAY support other formats
* If the application does not support linked images, the target is unavailable, not permitted or an unknown format the picture block should be skipped.
* Applications may make links available to users, this is of particular use when links are unsupported or of unsupported type

===== Image dimension fields =====
* The height, width, colour depth and 'number of colours' fields are for purely informational purposes. Applications MUST NOT use them for decoding purposes, but MAY display them to the user and MAY use them to make a decision whether to skip the block (for example if selecting the most appropriate among multiple blocks).
* Applications writing picture blocks MUST set these fields correctly OR set them all to zero.

===== Multiple blocks =====
* Multiple image blocks MAY be included as separate METADATA_BLOCK_PICTURE comments.
* There may only be one each of picture type (APIC type) 1 and 2 in a Vorbis stream.
* Block order is significant for some types and applications should preserve the comment order when reading or writing VorbisComment headers. The block order may be used to determine the order pictures are presented to the user.

===== Playback tests =====
Embedding a picture into the file might break playback of existing players (especially hardware players, software players could be updated easily). A workaround would be to link the picture within the tag. Furthermore users should become informed in some way that embedding a picture COULD cause problems (as stated above).

In order to test if there are playback problems, there are test files available [http://www.audioranger.com/coverart_mk.ogg here] and [http://www.audioranger.com/coverart_im.ogg here]. You're invited to download one of these test files (or both), test playback on your software and hardware players, and report the results here on the wiki.

'''Tested software players'''
* Audacious 1.5.1: no problem
* foobar2000: no problems
* Gnome: built-in preview playback: no problem
* MediaMonkey: no problems
* Media Player Classic (unicode build) 6.4.9.1: no problem
* RoarAudio: no problems (server and client side)
* Rythmbox 0.11.6: no problem
* Totem 2.24.3: no problem
* VLC 0.9.4/0.9.6: doesn't play
** Patch send to VLC to fix this - should get in 1.0.0
* WinAmp: no problems
* Windows Media Player 11: no problem
* XMPlay 3.4.2: no problem
* Nero ShowTime: no problem
* Songbird 1.8.0: no problem, able to show and edit embedded pictures

'''Tested hardware players'''
* Logitech Squeezebox: Supported as of January 2009 (server version 7.3.3)
* Sandisk Sansa Fuze (Firmware 01.01.22): Hangs up when trying to playback the demo file - had to reset the player
** Note: The "Fuze" can play ogg vorbis files which have embedded pictures from "Easytag"
* Cowon iAudio U3 (Firmware 1.29, 4 GB): works
* Cowon D2: no problem (latest Firmware: 2.59, 8GB Version)
* iRiver E100: no problem (latest Firmware: 1.16 G_U, 8GB Version)
* Samsung YP-R1: no problem (latest Firmware: 3.07, 16GB Version)

'''Tested tag editors'''
* Easytag 2.1.6: can open the file to edit the normal tag fields
* MP3Tag 2.42e: can open the file to edit the normal tag fields
* MP3Tag 2.47b: is able to show and edit embedded pictures

'''Tested other software'''
* Total Recorder: capable to work with artwork according to the specification.

==== Unofficial COVERART field (deprecated) ====
There also exists an unofficial, not well supported comment field named "COVERART". It includes a base64-encoded string of the binary picture data (usually a JPEG file, but this could be a different file format too). The disadvantages are that
* no additional information like a description about the cover art or its type (front cover, back cover etc.) is provided,
* the cover art can't be linked
* the base64 string is displayed within many tag editors as plain text because of their missing support for this "COVERART" field
* it may breaks the playback on hardware players because of a large VorbisComment header
The unofficial "COVERART" field is supported for example by such software as AudioShell (http://www.softpointer.com/AudioShell.htm) - read/write, and Total Recorder (http://www.totalrecorder.com/)- only read.

===== Conversion to METADATA_BLOCK_PICTURE =====
Old "COVERART" tags should be converted to the new METADATA_BLOCK_PICTURE tag (see above for its specification). This conversion is straightforward and is suggested to be done the following way:

* Decode the COVERART tag. A program MAY check the signature of the embedded picture in order to determine whether it is an allowed type. Lossless conversion from disallowed types to allowed types MAY be carried out.
* Fill out the FLAC block with the binary picture data. If the MIME type of the picture is unknown or can't be determined, the MIME type "image/" MAY be used instead. Supplying image dimensions, color depth etc. is optional (see specification above).
* In the absence of other information the picture type 'Other' should be used. Applications may want to allow users to select a default type or specify the type to use.
* Encode the new picture block, remove the COVERART tag from the comments and add the METADATA_BLOCK_PICTURE entry.
* If multiple tags are being converted the order of the METADATA_BLOCK_PICTURE tags should be the same as that of the COVERART tags they are replacing.

=== Chapter Extension ===

These are used to include navigation points, for example:
<pre>
CHAPTER001=00:00:00.000-->00:05:00.000
CHAPTER001NAME=Chapter 1
CHAPTER001URL=http://...
</pre>

See the [[Chapter Extension]] page for more details.

=== Date and time ===

The goal is to specify '''one''' standard format for describing date and/or time.

==== ISO proposal ====
The date format for any field describing a date must follow the ISO scheme: YYYY-MM-DD, shortened to just YYYY-MM or simply YYYY.

We have been recommending this usage with the DATE tag for some time. It is proposed that the spec be amended to include this information for machinability.

The time format for any field '''except''' track duration must be specified with leading T and ending with a time zone. Schemas with and without dates:
<pre>
YYYY-MM-DDTHH:MM:SS+TS
</pre>
<pre>
THH:MM+TZ
</pre>

=== ENCODER ===

The goal is to attribute encoder software. This value can be used in the future to determine which files can be improved by being re encoded with a newer version.

:'''Comment''': What is lacking from the vendor string present in the spec from the start? All libvorbis and encoder tunings I'm aware of have recorded the encoder version here.

Rationale for not using the vendor string:
* The vendor string is usually used to store the name and version of the underlying codec library
* The idea of ENCODER is to store the name of the user-visible application, for example <tt>ffmpeg2theora</tt>.
* It can be useful for debugging to store the name and version of the calling application.
* The libvorbis API does not let applications override the vendor string.

==== Proposal: Inclusion of URL in ENCODER value ====
The encoder field name must be a unique URL providing both encoder software name and version. If no unique URL address is available were both name and version is available; then the version number can be specified by separating with a space character. For example:

<nowiki>ENCODER=http://flac.sourceforge.net/ 1.2.1</nowiki>

* Note that ffmpeg2theora uses ENCODER, but does not include a url. ''Added by Rillian on September 17, 2007''

==== Proposal: ENCODED_BY ====

I've also seen ENCODED_BY. ''Added by Rillian on September 17, 2007''
: ENCODED_BY is usually the person who did the encoding. This should not be part of the recommendation due to legal problems around deliberate and accidental distribution to third parties. Basically the name of the encoder should not be included to protect encoders from their own egos and possible legal prosecution. ''Added by Aleksandersen on September 20, 2007''

=== Improving license data ===

The goal is to provide a method for proclaiming license and copyright information (basically clarifying ‘distribution rights (if any) and ownership’).

The [http://xiph.org/vorbis/doc/v-comment.html specification document] describes LICENSE and COPYRIGHT fields. But is not clear enough about whether these should be machine-readable.

We should consider working together with Creative Commons to have complementary and interlinked information on the Creative Commons and Xiph wikis. Refer to the [http://wiki.creativecommons.org/Ogg Ogg page] in the Creative Commons wiki.

==== New RIGHTS field name proposal ====
One proposal is to replace the COPYRIGHT and LICENSE field names with RIGHTS. RIGHTS must be a human-readable copyright statement. Basic example:

<nowiki>RIGHTS=Copyright © Recording Company Inc. All distribution rights reserved.</nowiki>

But this is not machine-readable. Adding two complementary field names should do the trick: RIGHTS-DATE, describing the date of copyright; and RIGHTS-URI, providing a method for linking to a license. Software agents can assume that multiple songs uses the sameURIs, such as in the case for Creative Commons. Full example:

<nowiki>RIGHTS=Copyright © 2019 Recording Company Inc. All distribution rights reserved.</nowiki> 
<nowiki>RIGHTS-DATE=2019-04</nowiki> 
<nowiki>RIGHTS-URI=http://somewhere.com/license.xhtml</nowiki>

Software such as for multimedia management and playback are encouraged to display the RIGHTS statement as a linked phrase using RIGHTS-URI.

RIGHTS-DATE does not need to be displayed as it is required in the human readable version by international copyright agreements. RIGHTS-DATE can be used to determine when a copyrighted work falls under the public domain and related matters. (''The Beatles''' copyright on their original studio recordings (not the remixes) are soon expiering. So mechanisms such as the RIGHTS-DATE are indeed required in music management and filesharing software!)

To remain machine-readable it would be required to have at most one instance of each RIGHTS field name. All fields would of course remain optional.

The ''Dublin Core Metadata Initiative'' recommends the use of ‘rights’ to describe license and copyright matters. The web feed format Atom 1.0 has implemented a rights element in their specification.

:'''Comment''': The triplet RIGHTS, RIGHTS-DATE, RIGHTS-URI is an example of structured metadata. VorbisComments are inherently unstructured, and this should be respected. Structured metadata belongs in a different stream, such as XML (using [[Metadata#XMLEmbedding|XMLEmbedding]]).

==== Improving existing fields proposal ====
Similar to the DATE tag above, we have generally recommended that a URL uniquely identifying the license be included in the LICENSE field to allow machine identification of the license. This is in agreement with the proposal in the Creative Commons wiki. Since the COPYRIGHT field is a human-readable statement of the copyright, like the proposed RIGHTS tag above, some people include a license url there. Therefore if a url can't be found in a LICENSE tag if any, applications should use one from the COPYRIGHT tag, if any. Contact information for verification, attribution, relicensing, etc. can be obtained from the COPYRIGHT field, but Creative Commons also recommend a separate CONTACT tag for this information. This is reasonable, so we propose it be included.

=== Geo Location fields ===

The existing LOCATION field is meant to carry a human readable location for the recording/creation of the media file.

Having geographical coordinates according to [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84] can be useful as well, especially in a form that can be machine parsed. The agreed format is similar to this [http://en.wikipedia.org/wiki/Geo_(microformat) geo microformat]:

GEO_LOCATION= ''latitude'' ; ''longitude'' [; ''elevation'' ]

where each value is a fixed point decimal number formatted in the C locale with a period (.) for the radix. Values are separated with a ';' and white space is not significant. The elevation is optional.

''latitude'' is the geo latitude location of where the media has been recorded or produced in decimal degrees according to WGS84 (zero at the equator, negative values for southern latitudes) (C double).

''longitude'' is the geo longitude location of where the media has been recorded or produced in decimal degrees according to WGS84 (zero at the prime meridian in Greenwich/UK, negative values for western longitudes). (C double).

''elevation'' is the geo elevation of where the media has been recorded or produced in meters according to WGS84 (zero is average sea level) (C double).

=== Replay Gain ===

The REPLAYGAIN_* fields implement the Replay Gain proposal for storing a track relative volume adjustment, which can be used to "fix" quiet or loud sounding Vorbis or FLAC streams. The set of tags is intended to be machine parsed, and has the following form:
<pre>
REPLAYGAIN_TRACK_GAIN=-7.03 dB
REPLAYGAIN_TRACK_PEAK=1.21822226
REPLAYGAIN_ALBUM_GAIN=-6.37 dB
REPLAYGAIN_ALBUM_PEAK=1.21822226
</pre>

See http://www.replaygain.org/ for detailed information about Replay Gain and how the different values are calculated.

=== Tantalos resource ID ===
Tantalos is a protocol to auto locate and access content in a network scope (normally 'LAN' but can also be bigger like 'company network'). It uses UUIDs to identify resources. There are two groups of those UUIDs: IDs generated using the meta data of the track and IDs generated in some other way (for example random IDs, see UUID specs). The later group may need to be passed with the track. The VCLT Playlist format (see below) uses 'HASH={UUID}id...' with hex-dash format for this (HASH={UUID}e278173d-4d6d-4c66-95ec-4ec85eedc7d1).
--[[User:Ph3-der-loewe|Ph3-der-loewe]] 02:05, 13 December 2011 (PST)

== Other (non-proposed field names) ==
=== VCLT playlist format ===
The VCLT playlist format uses some ''keys'' which look like VorbisComments but they aren't nor they are proposed to become (expect for HASH). This includes the keys STREAMURL, FILENAME, FILEURL, LENGTH, HASH (see above for this one), SIGNALINFO, AUDIOINFO and OFFSET. You can find more infos about those at [https://bts.keep-cool.org/wiki/Specs/VCLT https://bts.keep-cool.org/wiki/Specs/VCLT].

== Implementations ==

* [http://sbooth.org/importers/ OggImporter] – imports Ogg Vorbis and Ogg FLAC files to Spotlight.
* vorbiscomment – a commandline tool, part of [[VorbisTools]].
* [http://www.xiph.org/oggz/ oggz-comment] – a commandline tool, part of [[Oggz]] tool. It can add comments to multitrack and video files.

Talk:Metadata

2012-06-05T19:39:27Z

Martin.leese: /* IEEE Learning Object Metadata */ Tidied formatting (to make clearer who said what)

== IEEE Learning Object Metadata ==
The proposed solution is RDF + Dublin Core. Has anybody looked into supporting IEEE LOM, the Learning Object Metadata standard that I believe can incorporate Dublin Core? This is being adopted by key players in the e-learning world (IMS Global Learning, and SCORM), and would be valuable for the applications I am interested in.

Fred Kintanar ([[User:Fredkintanar05|Fredkintanar05]]), 30 January 2006 
Cebu City, Philippines

: Having just looked at the [http://ltsc.ieee.org/wg12/ IEEE LOM page], I see they have XML and RDF bindings defined. The current view seems to be that you package a RDF or RDF/XML description of the content into the Ogg stream, with Dublin Core being a minimum feature set (Dublin Core certainly doesn't provide everything one might want). Handlers would most likely ignore or "dumb-down" relations they don't understand. In that case this would certainly work, but at the moment there is no clear plan (details like references between and into logical streams haven't really been considered as far as I can tell).

: What you want to do may already be possible with [http://ltsc.ieee.org/wg12/ Annodex]; try their [http://lists.annodex.net/cgi-bin/mailman/listinfo/ mailing lists], or the [http://lists.xiph.org/mailman/listinfo/ogg-dev Ogg-dev] mailing list.

:[[User:Imalone|Imalone]] 05:48, 30 January 2006 (PST)

== MDMF (now renamed M3F) replacing VorbisComments ==

The article read:
<blockquote>
"The format [MDMF] will possibly replace VorbisComments altogether."
</blockquote>

To which Imalone responded:
:This seems unlikely, not least because VorbisComments are much simpler to implement and interpret. Current consensus is that this will be supplementary or take precedence.--[[User:Imalone|Imalone]] 06:21, 17 September 2007 (PDT)

::As I understand it, the purpose of MDMF is to replace VorbisComments for the use of ''structured'' metadata, allowing VorbisComments to revert to its orginally intended use of "short, text comments ... much like someone jotting a quick note on the bottom of a CDR." I will modify the article to say this. The Vorbis docs even state "arbitrary metadata belongs in a separate logical bitstream (usually an XML stream type) that provides greater structure and machine parseability". [[User:Martin.leese|Martin Leese]] 12:01, 18 September 2007 (PDT)

:::Then Vorbis will have to be replaced by a successor because else you get backwards compatibility issues when players try to read vorbis with the new meta data format and can't!!!!!! [[User:Xpete|Xpete]] 29 January 2008

::An Ogg container can contain more than one logical stream. [[M3F]] will be a separate logical stream, and will be separate from the [[Vorbis]] stream. As [[M3F]] does not touch [[Vorbis]], backwards compatibility will not be a problem. [[User:Martin.leese|Martin Leese]] 15:59, 29 January 2008 (PST)

== Meta data files ==

Meta data is handy and structured meta data handier.

However sometimes there is a lot of metadata and it's not handy to use some tagged metadata.

A general approach would make life very easy for a lot of people.
Allowing Ogg to include files as meta data (and folders). Enabling those files to be added, deleted changed opened as normal files with external programs. Or viewed with file managers. e.g. ad a tab meta data files in the File Properties dialog that displays the meta data files and sub folder(s).

This way Ogg doesn't have to make or support an complicated and advanced meta data file format for structuring the information itself. Ogg doesn't have to be able to decode them, only contain them which wouldn't be very difficult because it just holds files.
Making Ogg more efficient, streamlined and powerful at the same time.

How would this work?
In the files, there would be a folder called meta data files.
This folder would contain every meta data file as files.

The files could be made visible in the file system by adding a tab called meta data files.
This then could show all the relevant files and folder.
Enabling to browse the folder in the file as a normal folder in the file system would be a very good way of providing access for users and programs.

[[User:Vmol|Vmol]] 08:25, 22 August 2009 (MDT)

Skeleton

2012-06-04T20:12:15Z

Martin.leese: Fixed double redirect

#REDIRECT [[Ogg Skeleton 4]]

OggSkeleton

2012-06-04T20:12:01Z

Martin.leese: Fixed double redirect

#REDIRECT [[Ogg Skeleton 4]]

OpusFAQ

2012-05-24T17:31:58Z

Martin.leese: /* How does the quality of Opus compare to ? */

=== Is the SILK part of Opus compatible with the SILK implementation shipped in Skype? ===

No. The SILK codec, as submitted by Skype to the IETF was heavily modified as part of its integration within Opus. The modifications are significant enough that it is not possible to just write a "translator" and even sharing code between Opus and the "old SILK" would be highly non-trivial.

=== What is Opus Custom? ===

Opus Custom is an '''optional''' part of the Opus standard that allows for sampling rates other than 8, 12, 16, 24, 48 kHz and frame sizes other than multiples of 2.5 ms. Opus Custom requires additional out-of-band signalling that Opus does not normally require. Also, because it is an optional part of the specification, using Opus Custom may lead to compatibility problems. For these reasons, its use is discouraged outside of very specific applications, e.g.:
* ultra low delay applications where synchronization with the soundcard buffer is important.
* low-power embedded applications where compatibility with others is not important.

For almost all other types of applications, Opus Custom should not be used.

=== How do I use 44.1 kHz or some other sampling rate not supported by Opus? ===

In the vast majority of cases, the best way to support other sampling rates is to perform sample rate conversion to 48 kHz. Only in some very specific circumstances should Opus custom be used.

=== What are the licensing requirements? ===

The Opus source code is released under the BSD license, which is a very permissive Open Source license. Commercial use and distribution (including in proprietary software) is permitted, provided that some conditions specified in the license are met.

Opus is also covered by some patents, for which free usage rights are granted, under conditions that the authors believe are compatible with most (all?) open source licenses, including the GPL (v2 and v3).

=== How does the quality of Opus compare to other codecs? ===

=== Which implementation should I get? ===

Talk:VorbisComment

2012-05-08T16:27:15Z

Martin.leese: /* Proposal: Adding embedded Lyrics field */ Added attribution

== License and Copyright ==

Do notice that I proposed a simpler standard for those two tags a couple of months ago.

* COPYRIGHT = Name of Entity (e.g. Xiph.Org Foundation)

:: Should be renamed ‘RIGHTS’ (as proposed on the wiki page). Copyright... Well. It is not nice. We are talking about Distribution rights, anyways... ''Added by Aleksandersen on October 3, 2007''

* LICENSE = Link to license, only URI/IRIs allowed ( e.g. http://creativecommons.org/licenses/by/3.0/ )

:: But it lacks a way to determine machine readable date of rights. Such as with RIGHTS-DATE. ''Added by Aleksandersen on October 3, 2007''

This makes it simple for both users and machines to understand the data.
--[[User:Saoshyant|Ivo]] 16:33, 13 September 2007 (PDT)

== Comments by Ijabz ==

''The following was added by Ijabz on October 18, 2007''

I really like VorbisComments because in contrast with other metadata formats (e.g ID3,MP4 metadata) it is very simple to develop a programing interface, you can treat every field as a simple name-value pair without breaking anything, if a field value is formatted in a special way to aid machine parsing but your program doesnt know about it thats ok it wont break. Having seen how long it has taken for ID3v2.4 to be adopted I think Xiph would do better to improve VorbisComment (without breaking backwards compatability) rather than provide alternatives.

It only really has three drawbacks:

1. The list of official fields is too small, we need a definitive list of offical fields now that is much larger than it is now. These fields are not mandatory so I cant see any drawback in extending this list, but there seems to be a reluctance to actually do it. A reasonable approach would be to look at the list of defined frames in ID3 and provide vorbis equivalents where possible. Should also consider adding the list of tags added by [http://wiki.musicbrainz.org/PicardQt/TagMapping the Musicbrainz project], seeing as they are an opensource not for profit organisation whose main aim is to improve the quality of infdormation about recordings they appear to be a prefect partner.

2. VorbisComments do not provide support for binary data, and when anybody mentions this it is explained that the data should be added as a seperate multiplexed stream. I dont understand this solution and I'm not aware of any applications that actually do this so even if I implemented support for it in one program it would be of limited use. The most important binary data for audio files is cover art images and without support for these OggVorbis is at a serious disadvantage. [http://www.softpointer.com/AudioShell.htm Audioshell] implements it by base64 encoding the image, this seems a perfectly sensible solution that would be easy to implement, and would work for any binary data.

3. VorbisComments do make it more difficult to show complex relationships and an XML format would proably be better as expressing these. However if a relatiuonship is complex it is probably too complex to be of much interest to anybody, however it can still be done using VorbisComment. For example the following example is given within the Metadata wiki page:
<pre>
How do you indicate which artist played tenor sax in the solo?
</pre>
This is a very specific request, but could be done by adding a subfield character (I've used a colon in this example) allowing machine parsing of related attributes
<pre>
ARTIST_INSTRUMENT_MUSICALPASSAGE="fred:tenorsaxophone:solo"
</pre>
Or you could amend the Fieldname so it supported a way of linking fields,e.g:
<pre>
ARTIST-1:fred
ARTIST-2:jane
INSTRUMENT-1:tenorsaxophone
MUSICPASSAGE-1:solo
</pre>
so the rule is if a field ends with (-n) all fields ending with the same value of n are linked, I dont see how this breaks things

:On drawback 2, VorbisComments were designed to be text-only. As you point out, the intention was to put binary data in a separate logical bitstream. Unfortunately, at the moment, adding such a stream to an [[Ogg]] container breaks many players. An initiative is in progress to address this using [[Ogg Skeleton]]. As for cover art, there is now such a proposal using the VorbisComment tag [[VorbisComment#Cover_art|METADATA_BLOCK_PICTURE]].

:On drawback 3, VorbisComments are inherently unstructured. For complex relationships, it would be better to use a system which has built-in structure such as XML. [[M3F|Multimedia Metadata Format (M3F)]] is such a draft proposal.

:[[User:Martin.leese|Martin Leese]] 19:52, 1 July 2009 (PDT)

== Character encoding ==

''Moved from article as it is not a good idea. The section was added by Aleksandersen on September 13, 2007''

The goal is to be offer better support for more languages and make machine processing faster.

The specification should be a little more strict to achieve this.

=== Proposals ===

Field names may be UTF-8 and all UPPERCASE for easier machine processing.

Allowing tag names to be UTF-8 instead of ASCII is a backwards-incompatible spec change. If we did this, requiring that the case mapping happen in the tagging application rather than in decoders is reasonable, since case mapping in unicode is non-trival.

The original argument for ASCII was that we need standardized tag names for interoperability, so there's no point in being able to localize them, and we might as well go with our native prejudice. Localizing the values should be done by appending a language code to the tag, since this is both machinable and there may be collisions between translated tag names.

:UTF-8 is a bad idea in field names. The field names are for machine interpretation, localisation should be done on the software side. UTF-8 introduces matching problems (canonical form) and encoding/decoding problems (difficulty in finding length of a string). Please sign comments; I ''think'' the above is a cumulative set of comments, but no idea.--[[User:Imalone|Imalone]] 01:11, 17 September 2007 (PDT)

== Attributing involved parties ==

''Moved from article as it is not the consensus view. The section was added by Aleksandersen on September 13, 2007''

The goal is to attribute more persons and organisations involved in audio and music productions to make room for more advanced search and sorting.

NO PROPOSALS! VorbisComments need a lot of extension beyond just the ARTIST field name. See work at [[M3F|Multimedia Metadata Format (M3F)]], the proposed XML replacement for VorbisComments for structured metadata.

== Proposal: Adding embedded Lyrics field ==

Similar to mp3's id3v2-tags lyrics and synchronized lyrics (SYLT) fields - available since 1998. Missing this every day.

Maybe relevant for M3F only? posted there too. --[[User:Oggfan|Oggfan]] 07:32, 8 May 2012 (PDT)

Synchronized lyrics may also be embedded as a [[Kate]] text stream, though patches to get playback in misc audio players are mostly been ignored (isn't that the fate of most patches to anything ?). --[[User:Oggfan|Oggfan]] 07:43, 8 May 2012 (PDT)

M3F

2012-05-08T16:23:58Z

Martin.leese: /* Describing related texts (lyrics and subtitles) */ Typo (moved space)

{{draft}}

See other [[Metadata|suggested metadata methods]].

This document describes the '''proposed''' ''Multimedia Metadata Format'' (M3F) for the Ogg container. The format is built on the Extensible Markup Language (XML). It is intended to describe any kind of multimedia (audio, video, text, images, etc) that can reside in the [[Ogg|Ogg container]].

==Format description==
''Multimedia Metadata Format'' documents describe media resources in Ogg containers and stream. The format can link resources with one another for media players that support rendering multiple kinds of media. (Such as audio tracks and albumart; and video and commentary audio overlays.)

No element except ‘metadata’ is required. But some elements have required attributes.

All dates must be formatted as ''ISO 8601:2000 – International Date and Time Format''.

===XML, declaration, and name spaces===
A metadata document must have a standard XML declaration on the very first line. The XML deceleration must contain the ‘version’ and ‘encoding’ attributes.

<code><pre><?xml encoding="UTF-8" version="1.0" ?></pre></code>

Encoding should default to Unicode/UTF-8. XML version should always use the oldest version were desired features are available, as per the XML specifications. Only when features not pressent in older XML versions are required should a newer version be used.

In addition the XML attributes ‘base’ and ‘lang’ may be used. Refer to them with an ‘xml:’ prefix if used in any element except the XML declaration. The optional ‘base’ attribute defines the base URI for compleating relative URIs. This value must default to the current Ogg Container. (Basically all other URIs in the format is relative. The attribute is usefull for formats other than Ogg.) The attribute is inherited by all children. The optional ‘lang’ element describes the language of a resource using three letter ''ISO 639-3'' codes. Note that this element should only be used on the ‘resource’ element or in the XML declaration for easier software parsing. The attribute is inherited by all children and have no default value.

The ‘metadata’ element is required as the top level container. It must contain at least one XML name space defining the format via the ‘xmlns’ attribute. (The URL used in the example is not the final address as no name space have been created yet.)

<code><pre><metadata xmlns="http://xmlns.xiph.org/metadata/0.1/">
[…]</metadata></pre></code>

The '''Multimedia Metadata Format''' can be extended by including multiple XML name spaces to the ‘metadata’ element. As with any other XML format: Software may not add, modify, or expect elements and attributes not defined by a XML name space.

====Languages====
The ‘xml:lang’ can be used on any element, and it is inherited from parent elements. In the below example, the first title element inherits ‘eng’ as its language from the ‘resource‘ parent element. A player may present any title, but should prefer the global language (language of the ‘metadata’ element) or the user’s language, as specified by the player. If the player’s interface language (or possibly a dedicated metadata language option) is German (ISO 639-3:deu), than it should assume the user prefers the German title.

<code><pre><resource […] xml:lang="eng">
<title>The Science of Sleep</title>
<title xml:lang="deu">Anleitung zum Träumen</title>
<title xml:lang="ita">La science des rêves</title></resource></pre></code>

===Addressing the media resource===
Media resources in the stream is described as ‘resource’ children of the ‘metadata’ element. Each resource element must have a ‘oggserial’ linking it to the correct chunk in the stream. It must also have a ‘type’ attribute with the native MIME type of the resource.

<code><pre><resource oggserial="0×EXAMPLE" type="audio/vorbis">
[…]</resource></pre></code>

The ‘uri’ attribute may be used in stead of ‘oggserial’. For ogg serials the URI would be ‘urn:oggserial:#0×EXAMPLE’. (Other container and native file formats may specify any URI that works with that format.)

Resource elements can also have an optional unique ‘xml:id’ attribute. The ‘xml:id’ attribute is used as a label when the resource needs to be addressed by another resource element.

<code><pre><resource xml:id="unique-resource-id" […]>
[…]</resource></pre></code>

Note: It is good practise to include every resource in a stream as a resource element. This makes it easier to link and describe relationships with other resources. (Such as with films and subtitles; and music and albumart.)

===Describing the media resource===
There are many children elements of the ‘resource’ element. All are optional and everyone can be used with any resource. Though media type spesific children are grouped together. These children does not make much sense with all media types

=====Describing audiences=====
The ‘audience’ element is a self-regulated filtering mechanism intended for parental control and self-regulated filtering. The optional ‘nudity’ attribute is a space separated list with one or more of the following values ‘breasts’, ‘buttocks’, and ‘genitals’. The optional ‘sexual’ attribute is a space separated list of with one or more for the following values ‘kissing’, ‘sexact’, ‘touching’, ‘sexlanguage’, ‘erections’ and ‘erotica’. The optional ‘violence’ attribute is a space separated list with one or more of the following values ‘rape’, ‘human-injury’, ‘animal-injury’, ‘anime-injury’, ‘human-blod’, ‘animal-blod’, ‘anime-blod’, ‘human-torture’, ‘animal-torture’, and ‘anime-torture’. The optional ‘language’ atribute is a space separated list with one or more of the following values ‘vulgar’, ’swear’, and ‘mild’. The optional ‘harmful’ attribute is a space separated list with one or more of the following values ‘tobacco’, ‘alcohol’, ‘drug’, ‘weapons’, ‘example-dangerous’, ‘horror’, and ‘discrimination’. The required ‘context’ attribute is a space separated list with one or more of the following values ‘artistic’, ‘educational’, ‘medical’, ’sports’ and ‘news context’.

<code><pre><audience context="education" language="mild" nudity="sexact kissing" […] /></pre></code>

Note: The filters are based on ''Internet Content Ration Associations''' (ICRA) work. See their [http://www.icra.org/label/generator/ label generator] for full meaning of values.

=====Describing categories=====
The ‘category’ element describes the listing genre of the resource. The required ‘sort’ attribute describes the preferred genre for listing.

<code><pre><category sort="metal">
[…]</category></pre></code>

The optional ‘genre’ child element describes more in-depth sorting for the resource.

<code><pre><category sort="metal">
<genre>symphonic metal</genre>
<genre>goth metal</genre>
</category></pre></code>

=====Describing collections=====
Media resources may appear in collections (DVD set boxes, CD albums, etc.). The ‘collection’ element describes the resources relation and order/place in collections. The optional ‘date’ attribute describes the date the collection was made publicly available (its ‘release date’). The optional ‘track’ attribute describes the resource's order/place in the collection. The optional ‘tracks’ attribute describes the total number of resources in the collection. The optional ‘uri’ attribute should uniquely identify the collection as a whole.

<code><pre><collection date="2019-01-15" track="2" tracks="12" uri="urn:x-isrc:0123456789">
[…]</collection></pre></code>

The optional ‘artwork’ child element links the collection to a image resource. The required ‘uri’ attribute should either be a resource's ‘id’ attribute value with a ‘#’ prefix (as below) or a web URL resource. The optional ‘type’ attribute should be the MIME type of the image resource. The attribute should not be used when linking to other internal resources; but is encurraged when linking to external resources (such as web URLs).

<code><pre><collection>
<artwork uri="#embedded-image" />
</collection></pre></code>

The optional ‘title’, ‘subtitle’, and ‘tagline’ child elements function as the ‘resource:title’ element.

<code><pre><collection>
<title>Great Audio VI</title>
<tagline>Music that rocks you!</tagline>
</collection></pre></code>

Note that CD singles are indeed collections too.

=====Describing encodings=====
The ‘encoding’ element describes the encoding or digitalization of the resource.

<code><pre><encoding>
[…]</encoding></pre></code>

The optional ‘date’ child element describes when the last file encoding happen. When the file is re-encoded the original date of encoding should be preserved, and another date element should be added with the date of re-encoding.

<code><pre><encoding>
<date>2019-01-21</date>
</encoding></pre></code>

The optional ‘source’ child element describes the original media source for the encoding. The required ‘media’ attribute must be either ‘cd’, ‘dvd’, ‘tape’, ‘web-stream’, ‘tv-stream’, ‘radio-stream’, ‘file’, or ‘unknown’. The optional ‘uri’ attribute should uniquely identify the media.

<code><pre><encoding>
<source media="cd" uri="urn:x-isrc:0123456789" />
</encoding></pre></code>

The optional ‘software’ child element describes the softwares used for the encoding. The optional ‘title’ attribute describes the software name. The optional ‘version’ attribute describes the software version. The required ‘uri’ attribute should uniquely identify the software (and version).

<code><pre><encoding>
<software title="flac" version="2.2" uri="http://xiph.org/flac/" />
</encoding></pre></code>

Note: The software version attribute is important for one reason; It makes it so much easier to find out what files needs to be re-encoded (from a huge collection) if there ever were a bug in a software release.

=====Describing performers=====
The ‘performers’ element describes by whom the resource was performed. The unrequired ‘sort’ attribute describes the preferred performer for listing. (This sorting attribute was included for backwards compatibility with music library managers/players that lists only one artist's name.)

<code><pre><performers sort="White Stripes, The">
[…]</performers></pre></code>

The optional ‘person’ child element describes an performer. The ‘name’ child element describes the performer’s name.
<code><pre><performers>
<person>
<name>Jack White</name></person></performers></pre></code>

======Musicans======
The required ‘musician’ child element has no value. The optional ‘instrument’ child element describes the instrument used by the performer, with one of the following values ‘wind’, ‘lamellophone’, ‘percussion, ‘string’, ‘voice’, ‘electronic’, and ‘keyboard’. Two additional value to this child element is ‘vocal’, and ‘lead-vocal’.

<code><pre><performers>
<person>
<name>Jack White</name>
<musician />
<instrument>string</instrument>
<instrument>keyboard</instrument>
<instrument>lead-vocal</instrument></person></performers></pre></code>

Note: When searching for ‘Jack White’ as a guitarist the above example should suffice as a guitar is grouped under string instrument. This should be considered when implementing the above elements in search engines.

======Actors======
The required ‘actor’ child element’s optional ‘portrait’ attribute describes a fictional name an actors portraits in a movie (his role).
<code><pre><performers>
<person>
<name>Gael García Bernal</name>
<actor portrait="Stéphane Miroux" /></person></performers></pre></code>

======Other and organisations======
Optional person elements can contain ‘director’, ‘produser‘, and ‘writer’.
<code><pre><performers>
<person>
<name>Michel Gondry</name>
<director /></person></performers></pre></code>

The ‘organisation’ child element describes organisations involved in the production of the resource. The optional ‘uri’ attribute describes the organisation using an (unique?) URI.
<code><pre><performers>
<organisation uri="http://partizan.com/">Partizan</organisation></performers></pre></code>

=====Describing related texts (lyrics and subtitles)=====
The ‘texts’ element links media resources with CMML text resources such as song lyrics and film subtitles in the stream. The required ‘uri’ must point to another resource's id attribute or an external web URL resource. The optional ‘type’ attribute specifies the MIME type of external resource.) It is not encouraged to use the type nor URL option. Keep things in the stream, so to speak.)

<code><pre><texts uri="#example-text-resource" /></pre></code>

=====Describing recordings=====
The ‘recording’ element describes recording conditions.

<code><pre><recording>
[…]</recording></pre></code>

The optional ‘date’ child element describes when the recording was made.

<code><pre><recording>
<date>2018-10-17</date>
</recording></pre></code>

The optional ‘duration’ child element describes how long the recording lasts. This value must be specified as a colon separated value containing days:hours:minutes:seconds:milliseconds. When the value is low enough to not use a field it should be left blank or have the value zero (‘0’). The below examples says zero days, zero hours, seven minutes, four seconds, and 54 milliseconds.

<code><pre><recording>
<duration>::07:04:54</duration>
</recording></pre></code>

Note: When displaying durations in players; it might be better to convert days to hours, and visa versa. This recommendation does not specify in which cases this should be done. Duration and time is presented in different ways according to local variation (and user preference). Though displaying a shortened (lave out the null values) full time according to local variations will provably be the best way. Example: ‘2 days, 23 hours, and 18 seconds.’ OR a converted to days ‘2,96 days.’ Displaying ‘2:23::18:’ (same value as previous examples) may be confusing to users who are not used to this format. Even though it is the shortest way to display the full duration.

The optional ‘location’ child element describes when the recording was made in a human readable-way. The optional ‘lat’ and ‘long’ attributes are the machine-readable latitude and longitude position of the recording.

<code><pre><recording>
<location lat="22.20N" long="114.11E">Hong Kong, China, Earth</location>
</recording></pre></code>

=====Describing rights=====
The ‘rights’ element describes the Copyright and license status of the resource.

<code><pre><rights>
[…]</rights></pre></code>

The optional ‘date’ child element describes when the Copyright were put in place. This is especially useful when determining when a work's Copyright expires.

<code><pre><rights>
<date>2018-10-20</date>
</rights></pre></code>

The optional ‘license’ child element is a short and human-readable version of the full license.

<code><pre><rights>
<license>© 2018 Recording Company. All distribution rights reserved.</license>
</rights></pre></code>

The optional ‘link’ child element can point to any URI via it's ‘uri’ attribute where a full version of the license is available. This means it can be pointed to a ‘resource’ element via it's ‘id’ attribute as well!
<code><pre><rights>
<link type="text/html" uri="http://licenses.record-company.com/artist.html" />
</rights></pre></code>

=====Describing titles, subtitles, and taglines=====
The ‘title’ element describes the resource's title.

<title>Awesome Audio Track</title>

The ‘subtitle’ element describes secondary title.

<subtitle>The Sound of Music</subtitle>

The ‘tagline’ element describes promotional taglines and slogans.

<tagline>Get to the real sound!</tagline>

==Examples==

See [[M3F example|Multimedia Metadata Format example page]].

==History==
* 2007-11-25 – Began work with simplifying the format.
* 2007-09-08 – Wiki page created based on original format and suggestions from the mailing list.
* 2007-09-06 – Format proposed on the ogg-dev mailing list by [[User:Aleksandersen|Daniel Aleksandersen]].

Chapter Extension

2012-05-06T00:21:38Z

Martin.leese: /* Further Fields */ Replaced colon to suppress automatic link (to nowhere)

Chapters are a means of providing direct and semantically relevant navigation points for a media file. On particular use case are so-called [http://en.wikipedia.org/wiki/Enhanced_podcast "enhanced podcasts"], i.e. audio files with additional chapter markers.

Chapters are typically provided for a recorded file, not for a live resource.

Since chapters are used for navigation - in particular to avoid having to listen to large amounts of undesired content in order to get to desired content - it is important that the information about chapters is available at the start of a media file to be able to be displayed without having to decode the media file. Therefore, we regard chapters as header-style metadata.

Header-style metadata has traditionally been transported in [[VorbisComment]] headers inside Ogg.

== Format ==

We therefore propose an extensions to VorbisComment for transporting chapters. We introduce VorbisComment fields called CHAPTERxxx and CHAPTERxxxNAME with xxx being a number between 000 and 999. (1000 chapters are assumed to be sufficient.)

The value for the CHAPTERxxx field name is the start time of the chapter (Hour:Min:DecimalSeconds), "-->" (U+002D, U+002D, U+003E), and the end time (Hour:Min:DecimalSeconds). See the [[#Examples|examples]] below.

The value for the CHAPTERxxxNAME field name is just a text string (8 bit clean UTF-8 encoded values, as is required for VorbisComments).

This should basically support the same input format that [http://savvyadmin.com/adding-chapters-to-videos-using-mkv-containers/ Matroska chapters] support, too.

== Examples ==

An example chapter file with two sequential chapters:

CHAPTER001=00:00:00.000-->00:05:00.000
CHAPTER001NAME=Chapter 1
CHAPTER002=00:05:00.000-->00:10:00.000
CHAPTER002NAME=Chapter 2

Another example chapter file with a chapter and three hierarchically structured subchapters:

CHAPTER001=00:00:00.000-->00:06:00.000
CHAPTER001NAME=Chapter 1
CHAPTER002=00:00:00.000-->00:02:00.000
CHAPTER002NAME=Chapter 1.1
CHAPTER003=00:00:02.000-->00:04:00.000
CHAPTER003NAME=Chapter 1.2
CHAPTER004=00:00:04.000-->00:06:00.000
CHAPTER004NAME=Chapter 1.3

== Further Fields ==

Other fields can also be used to support enhanced podcasts:

* a field to extend chapters with a url to navigate to while listening to a chapter of a podcast:

CHAPTERxxxURL=http://...

== WebVTT ==

A more modern means of specifying chapters is through [http://dev.w3.org/html5/webvtt/#webvtt-file-using-chapter-title-text WebVTT files that use cues with chapter titles].

Opus

2012-05-02T17:10:53Z

Martin.leese: Created #REDIRECT

#REDIRECT [[OggOpus]]

Chapter Extension

2012-04-11T18:27:08Z

Martin.leese: /* Further Fields */ Typo

Chapters are a means of providing direct and semantically relevant navigation points for a media file. On particular use case are so-called [http://en.wikipedia.org/wiki/Enhanced_podcast "enhanced podcasts"], i.e. audio files with additional chapter markers.

Chapters are typically provided for a recorded file, not for a live resource.

Since chapters are used for navigation - in particular to avoid having to listen to large amounts of undesired content in order to get to desired content - it is important that the information about chapters is available at the start of a media file to be able to be displayed without having to decode the media file. Therefore, we regard chapters as header-style metadata.

Header-style metadata has traditionally been transported in [[VorbisComment]] headers inside Ogg.

== Format ==

We therefore propose an extensions to VorbisComment for transporting chapters. We introduce VorbisComment fields called CHAPTERxxx and CHAPTERxxxNAME with xxx being a number between 000 and 999. (1000 chapters are assumed to be sufficient.)

The value for the CHAPTERxxx field name is the start time of the chapter (Hour:Min:DecimalSeconds), "-->" (U+002D, U+002D, U+003E), and the end time (Hour:Min:DecimalSeconds). See the [[#Examples|examples]] below.

The value for the CHAPTERxxxNAME field name is just a text string (8 bit clean UTF-8 encoded values, as is required for VorbisComments).

This should basically support the same input format that [http://savvyadmin.com/adding-chapters-to-videos-using-mkv-containers/ Matroska chapters] support, too.

== Examples ==

An example chapter file with two sequential chapters:

CHAPTER001=00:00:00.000-->00:05:00.000
CHAPTER001NAME=Chapter 1
CHAPTER002=00:05:00.000-->00:10:00.000
CHAPTER002NAME=Chapter 2

Another example chapter file with a chapter and three hierarchically structured subchapters:

CHAPTER001=00:00:00.000-->00:06:00.000
CHAPTER001NAME=Chapter 1
CHAPTER002=00:00:00.000-->00:02:00.000
CHAPTER002NAME=Chapter 1.1
CHAPTER003=00:00:02.000-->00:04:00.000
CHAPTER003NAME=Chapter 1.2
CHAPTER004=00:00:04.000-->00:06:00.000
CHAPTER004NAME=Chapter 1.3

== Further Fields ==

Other fields can also be used to support enhanced podcasts:

* a field to extend chapters with a url to navigate to while listening to a chapter of a podcast:

CHAPTERxxxURL=http://...

== WebVTT ==

A more modern means of specifying chapters is through [http://dev.w3.org/html5/webvtt/#webvtt-file-using-chapter-title-text WebVTT files that use cues with chapter titles].

Talk:Ambisonics

2012-04-10T14:43:06Z

Martin.leese: /* Not for Delete */ Formatting

== Not for Delete ==

I deleted the <nowiki>{{delete}}</nowiki> template, so thought I had better
explain why. I have joined this Wiki because it looks like you guys have an
interest in Ambisonics. I can help with this. However, I need you to tell
me what you are looking for from Ambisonics. For the moment, I have listed
some resources on Ambisonics, and included a short discussion on how the Ogg
formats could improve on the
[http://www.ambisonicbootlegs.net/Members/mleese/file-format-for-b-format/ ".amb"]
and
[http://www.ambisonicbootlegs.net/Members/mleese/file-format-for-uhj/ ".uhj"]
specifications.

Ambisonics is mentioned on the [[OggPCM]] page, and I have made some minor
edits to that page.

Please let me know what else would be useful to you. [[User:Martin.leese|Martin Leese]] 22:14, 27 January 2007 (PST)

: I believe the <nowiki>{{delete}}</nowiki> template used on a discussion page indicates only that ''discussion'' page should be deleted as it has been created by a spammer. Obviously doesn't matter now that there's real content here, but I don't think it was a proposal to delete the ambisonics page itself. [[User:Imalone|Imalone]] 05:34, 27 March 2007 (PDT)

Actually, both the article ''and'' Talk page had the <nowiki>{{delete}}</nowiki> template on them. I deleted both <nowiki>{{delete}}</nowiki>s. My comments above were meant to be about the article; obviously I should have made that clearer. [[User:Martin.leese|Martin Leese]] 22:23, 27 March 2007 (PDT)

== Resources ==

Hey, Martin.

I've put a link to Richard Lee's index of stuff related with Ambisonics, however I have no time to check its details to explain in our article here what a user can find there. If you do not mind, and have the time, please do so. I think the more resources, the better.--[[User:Saoshyant|Saoshyant]] 06:42, 2 March 2007 (PST)

User:Martin.leese

2012-04-10T14:41:23Z

Martin.leese: /* Ambisonic credentials */ Tweak

== E-mail address & website ==

For my e-mail address, please see
[http://members.tripod.com/martin_leese/ my website].

== Ambisonic credentials ==

I have joined this Wiki because it looks like you guys have an interest in Ambisonics. I can help with this. I have been following Ambisonics since 1977, and have owned an Ambisonic decoder (a Minim AD-7) since 1994. I also created and maintain the [http://members.tripod.com/martin_leese/Ambisonic/faq_latest.html Ambisonic Surround Sound FAQ]. More recently, I was involved in defining the
[http://members.tripod.com/martin_leese/Ambisonic/B-Format_file_format.html ".amb"] and [http://members.tripod.com/martin_leese/Ambisonic/UHJ_file_format.html ".uhj"] specifications for dowloadable B-Format and two-channel UHJ files. I have
also proposed the [http://members.tripod.com/martin_leese/Ambisonic/G-Format_chunk.html ".amg"] file format for downloadable G-Format files. However, I do not work in pro-audio; I am just a domestic listener.

== [[Ambisonics]] on XiphWiki ==

In January 2007, I found the [[Ambisonics]] page on this Wiki marked for deletion. I removed this, and created a page discussing some of the problems of handling [[Ambisonics|Ambisonic]] B-Format, UHJ format, and G-Format.

== External resources on Ambisonics ==

* There is now a set of [http://en.wikipedia.org/wiki/Ambisonics Wikipedia articles on Ambisonics].
* Of particular relevance is the [http://members.tripod.com/martin_leese/Ambisonic/B-Format_file_format.html ".amb" specification] for downloadable B-Format files. There are currently over 100 pieces available in this format [http://www.ambisonia.com for free download]. Most of these are first-order full-sphere soundfields. The ".amb" spec has some limitations which it would be useful to overcome. ''The Ambisonia.com website has ceased to exist. Its content will be resurrected at the University of York, although this is taking a little time.''
* There is also the [http://members.tripod.com/martin_leese/Ambisonic/UHJ_file_format.html ".uhj" specification] for downloadable two-channel UHJ files, although it is not currently in use. The ".uhj" spec also has some limitations which it would be useful to overcome.
* I have proposed a [http://members.tripod.com/martin_leese/Ambisonic/G-Format_chunk.html ".amg" specification] for downloadable G-Format files.
* [http://members.tripod.com/martin_leese/Ambisonic/ My website] has many pages on Ambisonics (including at the bottom links to other Ambisonic websites).

== Useful links (really here for my benefit) ==

* [[Special:Longpages]]
* [http://wiki.xiph.org/index.php?title=Ambisonics&curid=909&action=history History:Ambisonics]

User:Martin.leese

2012-04-10T14:36:11Z

Martin.leese: Updated broken links + tidy

== E-mail address & website ==

For my e-mail address, please see
[http://members.tripod.com/martin_leese/ my website].

== Ambisonic credentials ==

I have joined this Wiki because it looks like you guys have an interest in Ambisonics. I can help with this. I have been following Ambisonics since 1977, and have owned an Ambisonic decoder (a Minim AD 7) since 1994. I also created and maintain the [http://members.tripod.com/martin_leese/Ambisonic/faq_latest.html Ambisonic Surround Sound FAQ]. More recently, I was involved in defining the
[http://members.tripod.com/martin_leese/Ambisonic/B-Format_file_format.html ".amb"] and [http://members.tripod.com/martin_leese/Ambisonic/UHJ_file_format.html ".uhj"] specifications for dowloadable B-Format and two-channel UHJ files. I have
also proposed the [http://members.tripod.com/martin_leese/Ambisonic/G-Format_chunk.html ".amg"] file format for downloadable G-Format files. However, I do not work in pro-audio; I am just a domestic listener.

== [[Ambisonics]] on XiphWiki ==

In January 2007, I found the [[Ambisonics]] page on this Wiki marked for deletion. I removed this, and created a page discussing some of the problems of handling [[Ambisonics|Ambisonic]] B-Format, UHJ format, and G-Format.

== External resources on Ambisonics ==

* There is now a set of [http://en.wikipedia.org/wiki/Ambisonics Wikipedia articles on Ambisonics].
* Of particular relevance is the [http://members.tripod.com/martin_leese/Ambisonic/B-Format_file_format.html ".amb" specification] for downloadable B-Format files. There are currently over 100 pieces available in this format [http://www.ambisonia.com for free download]. Most of these are first-order full-sphere soundfields. The ".amb" spec has some limitations which it would be useful to overcome. ''The Ambisonia.com website has ceased to exist. Its content will be resurrected at the University of York, although this is taking a little time.''
* There is also the [http://members.tripod.com/martin_leese/Ambisonic/UHJ_file_format.html ".uhj" specification] for downloadable two-channel UHJ files, although it is not currently in use. The ".uhj" spec also has some limitations which it would be useful to overcome.
* I have proposed a [http://members.tripod.com/martin_leese/Ambisonic/G-Format_chunk.html ".amg" specification] for downloadable G-Format files.
* [http://members.tripod.com/martin_leese/Ambisonic/ My website] has many pages on Ambisonics (including at the bottom links to other Ambisonic websites).

== Useful links (really here for my benefit) ==

* [[Special:Longpages]]
* [http://wiki.xiph.org/index.php?title=Ambisonics&curid=909&action=history History:Ambisonics]

User:Martin.leese

2012-04-10T14:28:57Z

Martin.leese: /* External resources on Ambisonics */ Updated broken links

== E-mail address & website ==
For my e-mail address, please see
[http://members.tripod.com/martin_leese/ my website].

== Ambisonic credentials ==
I have joined this Wiki because it looks like you guys have an interest in Ambisonics. I can help with this. I have been following Ambisonics since
1977, and have owned an Ambisonic decoder (a Minim AD 7) since 1994. I also
created and maintain the
[http://members.tripod.com/martin_leese/Ambisonic/faq_latest.html Ambisonic Surround Sound FAQ].
More recently, I was involved in defining the
[http://www.ambisonia.com/Members/mleese/file-format-for-b-format/ ".amb"]
and [http://www.ambisonia.com/Members/mleese/file-format-for-uhj/ ".uhj"]
specifications for dowloadable B-Format and two-channel UHJ files. I have
also proposed the
[http://members.tripod.com/martin_leese/Ambisonic/G-Format_chunk.html ".amg"]
file format for downloadable G-Format files. However, I do not work in
pro-audio; I am just a domestic listener.

== [[Ambisonics]] on XiphWiki ==
I found that the [[Ambisonics]] page on this Wiki had been marked for
deletion. I removed this, and created a page discussing some of the
problems of handling [[Ambisonics|Ambisonic]] B-Format, UHJ format,
and G-Format.

== External resources on Ambisonics ==

* There is now a set of [http://en.wikipedia.org/wiki/Ambisonics Wikipedia articles on Ambisonics].
* Of particular relevance is the [http://members.tripod.com/martin_leese/Ambisonic/B-Format_file_format.html ".amb" specification] for downloadable B-Format files. There are currently over 100 pieces available in this format [http://www.ambisonia.com for free download]. Most of these are first-order full-sphere soundfields. The ".amb" spec has some limitations which it would be useful to overcome. ''The Ambisonia.com website has ceased to exist. Its content will be resurrected at the University of York, although this is taking a little time.''
* There is also the [http://members.tripod.com/martin_leese/Ambisonic/UHJ_file_format.html ".uhj" specification] for downloadable two-channel UHJ files, although it is not currently in use. The ".uhj" spec also has some limitations which it would be useful to overcome.
* I have proposed a [http://members.tripod.com/martin_leese/Ambisonic/G-Format_chunk.html ".amg" specification] for downloadable G-Format files.
* [http://members.tripod.com/martin_leese/Ambisonic/ My website] has many pages on Ambisonics (including at the bottom links to other Ambisonic websites).

== Useful links (really here for my benefit) ==
*[[Special:Longpages]]
*[http://wiki.xiph.org/index.php?title=Ambisonics&curid=909&action=history History:Ambisonics]

Nut Container

2012-03-11T18:55:00Z

Martin.leese: Removed SPAM link

This page collects opinions about the NUT container format.

* http://wiki.multimedia.cx/index.php?title=NUT
* http://ffmpeg.org/~michael/nut.txt
* http://fr.wikipedia.org/wiki/NUT_Container NUT at French Wikipedia

== Comparison with Ogg ==

Monty writes: "NUT is very similar to [[Ogg]] (at least when compared to the other contemporary systems). It draws the abstraction lines in different places but has roughly the same functionality and hits the same practical limitations when considered in a system more complex than a desktop video player.

"Nor can we take lightly the prospect of abandoning a hundred million installed copies of Ogg (including those in hardware) for no distinct practical benefit."

Chapter Extension

2012-03-09T22:16:08Z

Martin.leese: Changed to webvtt-style "-->" timestamp separators (with no whitespace)

Chapters are a means of providing direct and semantically relevant navigation points for a media file. On particular use case are so-called [http://en.wikipedia.org/wiki/Enhanced_podcast "enhanced podcasts"], i.e. audio files with additional chapter markers.

Chapters are typically provided for a recorded file, not for a live resource.

Since chapters are used for navigation - in particular to avoid having to listen to large amounts of undesired content in order to get to desired content - it is important that the information about chapters is available at the start of a media file to be able to be displayed without having to decode the media file. Therefore, we regard chapters as header-style metadata.

Header-style metadata has traditionally been transported in [[VorbisComment]] headers inside Ogg.

== Format ==

We therefore propose an extensions to VorbisComment for transporting chapters. We introduce VorbisComment fields called CHAPTERxxx and CHAPTERxxxNAME with xxx being a number between 000 and 999. (1000 chapters are assumed to be sufficient.)

The value for the CHAPTERxxx field name is the start time of the chapter (Hour:Min:DecimalSeconds), "-->" (U+002D, U+002D, U+003E), and the end time (Hour:Min:DecimalSeconds). See the [[#Examples|examples]] below.

The value for the CHAPTERxxxNAME field name is just a text string (8 bit clean UTF-8 encoded values, as is required for VorbisComments).

This should basically support the same input format that [http://savvyadmin.com/adding-chapters-to-videos-using-mkv-containers/ Matroska chapters] support, too.

== Examples ==

An example chapter file with two sequential chapters:

CHAPTER001=00:00:00.000-->00:05:00.000
CHAPTER001NAME=Chapter 1
CHAPTER002=00:05:00.000-->00:10:00.000
CHAPTER002NAME=Chapter 2

Another example chapter file with a chapter and three hierarchically structured subchapters:

CHAPTER001=00:00:00.000-->00:06:00.000
CHAPTER001NAME=Chapter 1
CHAPTER002=00:00:00.000-->00:02:00.000
CHAPTER002NAME=Chapter 1.1
CHAPTER003=00:00:02.000-->00:04:00.000
CHAPTER003NAME=Chapter 1.2
CHAPTER004=00:00:04.000-->00:06:00.000
CHAPTER004NAME=Chapter 1.3

== WebVTT ==

A more modern means of specifying chapters is through [http://dev.w3.org/html5/webvtt/#webvtt-file-using-chapter-title-text WebVTT files that use cues with chapter titles].

Talk:Chapter Extension

2012-03-08T16:43:21Z

Martin.leese: Added missing attribution + response

A field for chapter based urls is missing. I propose this:

CHAPTERxxxURL=http://...

[[User:Vemedio|Vemedio]] 08:17, March 8, 2012 (PST)

: What would be its purpose? To where would the URL take you? [[User:Martin.leese|Martin Leese]] 08:43, 8 March 2012 (PST)

Chapter Extension

2012-03-05T21:08:58Z

Martin.leese: Added section headings and details of format + tidy

Chapters are a means of providing direct and semantically relevant navigation points for a media file. On particular use case are so-called [http://en.wikipedia.org/wiki/Enhanced_podcast "enhanced podcasts"], i.e. audio files with additional chapter markers.

Chapters are typically provided for a recorded file, not for a live resource.

Since chapters are used for navigation - in particular to avoid having to listen to large amounts of undesired content in order to get to desired content - it is important that the information about chapters is available at the start of a media file to be able to be displayed without having to decode the media file. Therefore, we regard chapters as header-style metadata.

Header-style metadata has traditionally been transported in [[VorbisComment]] headers inside Ogg.

== Format ==

We therefore propose an extensions to VorbisComment for transporting chapters. We introduce VorbisComment fields called CHAPTERxxx and CHAPTERxxxNAME with xxx being a number between 000 and 999. (1000 chapters are assumed to be sufficient.)

The value for the CHAPTERxxx field name is the start time of the chapter (Hour:Min:DecimalSeconds), a dash (U+002D), and the end time (Hour:Min:DecimalSeconds). See the [[#Examples|examples]] below.

The value for the CHAPTERxxxNAME field name is just a text string (8 bit clean UTF-8 encoded values, as is required for VorbisComments).

This should basically support the same input format that [http://savvyadmin.com/adding-chapters-to-videos-using-mkv-containers/ Matroska chapters] support, too.

== Examples ==

An example chapter file with two sequential chapters:

CHAPTER001=00:00:00.000-00:05:00.000
CHAPTER001NAME=Chapter 1
CHAPTER002=00:05:00.000-00:10:00.000
CHAPTER002NAME=Chapter 2

Another example chapter file with a chapter and three hierarchically structured subchapters:

CHAPTER001=00:00:00.000-00:06:00.000
CHAPTER001NAME=Chapter 1
CHAPTER002=00:00:00.000-00:02:00.000
CHAPTER002NAME=Chapter 1.1
CHAPTER003=00:00:02.000-00:04:00.000
CHAPTER003NAME=Chapter 1.2
CHAPTER004=00:00:04.000-00:06:00.000
CHAPTER004NAME=Chapter 1.3

== WebVTT ==

A more modern means of specifying chapters is through [http://dev.w3.org/html5/webvtt/#webvtt-file-using-chapter-title-text WebVTT files that use cues with chapter titles].

Chapter Extension

2012-03-05T19:54:41Z

Martin.leese: Fixed broken link

Chapters are a means of providing direct and semantically relevant navigation points for a media file. On particular use case are so-called [http://en.wikipedia.org/wiki/Enhanced_podcast "enhanced podcasts"], i.e. audio files with additional chapter markers.

Chapters are typically provided for a recorded file, not for a live resource.

Since chapters are used for navigation - in particular to avoid having to listen to large amounts of undesired content in order to get to desired content - it is important that the information about chapters is available at the start of a media file to be able to be displayed without having to decode the media file. Therefore, we regard chapters as header-style metadata.

Header-style metadata has traditionally been transported in VorbisComment headers inside Ogg.

We therefore propose an extensions to VorbisComment for transporting chapters. We introduce VorbisComment fields called CHAPTERxxx and CHAPTERxxxNAME with xxx being a number between 000 and 999. We assume 1000 chapters to be sufficient.

An example chapter file with two sequential chapters:

CHAPTER001=00:00:00.000-00:05:00.000
CHAPTER001NAME=Chapter 1
CHAPTER002=00:05:00.000-00:10:00.000
CHAPTER002NAME=Chapter 2

Another example chapter file with a chapter and three hierarchically structured subchapters:

CHAPTER001=00:00:00.000-00:06:00.000
CHAPTER001NAME=Chapter 1
CHAPTER002=00:00:00.000-00:02:00.000
CHAPTER002NAME=Chapter 1.1
CHAPTER003=00:00:02.000-00:04:00.000
CHAPTER003NAME=Chapter 1.2
CHAPTER004=00:00:04.000-00:06:00.000
CHAPTER004NAME=Chapter 1.3

This should basically support the same input format that [http://savvyadmin.com/adding-chapters-to-videos-using-mkv-containers/ Matroska chapters] support, too.

A more modern means of specifying chapters is through [http://dev.w3.org/html5/webvtt/#webvtt-file-using-chapter-title-text WebVTT files that use cues with chapter titles].

Talk:Spread Open Media

2011-12-29T19:47:40Z

Martin.leese: Added headings + attribution

== Promotional Banners ==

Page should contain at least one of the campaign promotional banners. --[[User:Aleksandersen|Aleksandersen]] 10:02, November 25, 2007 (PST)

== Supporting Websites ==

The links to Vorbis supporting websites/music sources at vorbis.com seems incomplete. Bandcamp is not there and it seems to me that page should be linked to content and discussion here, maybe as part of Vorbis evangelism. --[[User:JLeclerc|JLeclerc]] 23:50, 28 December 2011 (PST)

Talk:PortablePlayers

2011-11-12T15:51:48Z

Martin.leese: Undo revision 13110 by DeclanDoyle (talk) SPAM

== Discontinued players ==
I think that discontinued players should be moved into a different section. Not necessarily removed, as many are still available on clearance/refurbished/used.

The question is, how to make the split? I see three possibilities:
# Discontinued players on a separate page
# same page, but separate top-level section. e.g.:
#* Current devices
#** Flash-memory devices
#** HD devices
#** CD/DVD devices
#* Discontinued devices
#** Flash-memory devices
#** HD devices
#** CD/DVD devices
# make a subsection within each section. e.g.:
#* Flash-memory devices
#**Current devices
#**Discontinued devices
#* HD devices
#**Current devices
#**Discontinued devices
#* CD/DVD devices
#**Current devices
#**Discontinued devices

I'll hold off any updates right now, but I'll check back in a few days/weeks/whenever and see if there's any opinions here. If there's no disagreement by then, and noone has beat me to it, I'll take the initiative. [[User:Bsammon|Bsammon]] 03:43, 30 May 2010 (UTC)

:Having sections for discontinued devices (on each subpage) is fine - but I suggest to avoid explicit ''Current devices'' sections. With a ''discontinued devices'' section on a page it is immediately clear that everything listed before is current.--[[User:Gsauthof|Gsauthof]] 10:09, 30 September 2011 (PDT)

== List of top five players ==
It would be a good idea to have a few (five?) players at the top with images that are considered to be the best *recent* devices. I don't think any of the MP3 using masses will use this page to choose their next music player unless it lists recent devices, and presents a choice of five or six at the top, with images, and links to sites that they can buy them from. Also, could someone put up a notice to remind people it's not OGG, or Ogg! It's Ogg Vorbis, or if you must, Vorbis. - thehumanerror 25th December 2006

I totally agree with the above. This page was next to useless for me when I was shopping for a Vorbis player since I was overwhelmed with choices. Add to that the fact that many products have been discontinued or cannot be bought new and there's a recipe for disaster. - erpo41 October 17th, 2007

I also agree with the above; the primary reason I am not using Ogg Vorbis (I keep a parallel collection of mp3 and flac files) is I cannot easily find a portable player. I don't know that reorganizing this wiki page will help. I did comb through this page; basically all of the listed hard disk players are from one off manufacturers or not being manufactured any more. There are plenty of nice flash storage based devices and cell phones (from Samsung and others), but that is not what I am looking for. Also, I'm not interested in hacking my iPod. (I do embedded linux development enough at work; I'll pay someone else to get my media player working). Until this is addressed, Ogg Vorbis is going to remain out of use; which is a shame because for every other reason it is the best (in my opinion). --Kevin Holzer, January 10, 2009

:Yes. This is a good idea. Create a section at the top. Polish it well. And perhaps add a free-licensed photo. Anyone up for it?--[[User:Saoshyant|Ivo]] 06:41, 17 October 2007 (PDT)

I would rather see just a simple feature matrix (sorted so that unavailable devices are listed at the bottom, or just not listed at all). See talk below. Maybe preferred choises could be raised to the top thought! I agree that current list is quite unusable.

:As of now, the page contains a feature matrix, which only lists current and available devices. Thus, when you check this page out for buying advice it should be more useful now, i.e. it has no overwhelming effect anymore. I consider the raised issues as '''done'''. --[[User:Gsauthof|Gsauthof]] 10:04, 30 September 2011 (PDT)

== Recording in Vorbis ==

I would like to know which Players can '''record''' in Vorbis?! -- [[User:217.186.150.213|217.186.150.213]] 17:03, 26 Dec 2004 (PST)

:Ditto. Absolutely vital information. Do any of the players listed also record in Vorbis? If anyone has experience with A player, please state specifically whether it does or does not record in Vorbis.[[User:Nickhill|Nickhill]] 15:04, 4 June 2006 (PDT)

::Never heard of one that does, and there isn't a fixed point reference encoder, which makes it unlikely.

== Pretec Allegro may need firmware update ==

I recently purchased a Pretec Allegro, but was unable to play Oggs for three months, until the firmware update was made available on 14 or 15 March 2005. Now it works well! (So far, listening to -q3 Oggs). I'd hope that units purchased after this date already has the firmware update, but you never know. Installing the update is as simple as placing the .rom on the USB-storage-device media (eg flash disk), starting up the unit, and pressing the play button. -- Hugo van der Merwe
: How much battery runtime do you get playing Oggs compared with playing mp3? [[User:Phr|Phr]] 02:05, 27 Aug 2005 (PDT)

== Any player with Removable Memory Cards ==

The NexBlack (see [[PortablePlayers]] ) has removable compact flash and batteries.

Every single Vorbis-capable portable player out there seems to come with built-in flash memory. Which is stupid, because I don't want to fire up my computer and plug in the player every time I get tired of the tracks on my player. Plus flash memory has a limited lifetime (write cycles) and so does your player with built-in memory. The same applies for built-in rechargable batteries.

Now when would you ever need to buy your second device without any moving parts if you could just change flash memory and batteries? Ok, that's the industrie's point of view but not mine. I want to go on vacation with music and batteries for one week of non-stop music - without a power source or computer nearby.

So, any hint to where I might find a portable audio player that can play back ogg vorbis files and uses SD flash cards (and preferably AAA-batteries) would be greatly appreciated.
* Me too! If the [http://enox.co.kr/2004/eng/product/product_830_01.asp Enox EMX-830] took SD cards it'd be perfect. --[[User:Rgm|rgm]] 14:41, 7 Nov 2005 (PST)

* SanDisk Sansa e250/e260/e270/e280 has a microSD-card slot. With ROCKbox it plays Ogg/Vorbis and more.[[User:Nostromo|Nostromo]] 15:26, 29 October 2007 (PDT)

----

The Pretec Allegro is not the slickest player out there, it's LCD backlight seems to give off a high-pitched whine, which not everyone can hear (it kind-of screams in my ears though, so I put the backlight timer on 1 second so it doesn't scream too long). It is, however, the only one I now know of that can play Oggs, and uses removable media. If you want a nicely portable device, you have to use Pretec's "iDisk tiny" usb flash disk, the only thing that will fit inside. You can also, however, connect some USB SD-card reader with it's cable, then listen to Oggs off of SD. A little unwieldy, but, it works, and is the only thing *I* know of. (I stopped following developments in December though, when I bought it...)

== Samsung / Yepp ==

Moved to [[Talk:PortablePlayersSamsungYepp]]

== UniBrain iZak ==

Apologies if this is the wrong place for this; I'm new to wikis.

The UniBrain iZak was added, then removed recently, with the comment that it doesn't claim to play Ogg Vorbis.

The FAQ is available here: [http://www.unibrain.com/support/FAQ_iZak.htm iZak FAQ] and Question/Answer 24 says:

'22. Can iZak™ support OGG audio files?

Yes, iZak™ fully supports OGG playback using the latest firmware.'

:I was the one that removed it. In their specs linked from the main page, I saw that they listed only MP3 and WMA support for music formats. Obviously they need to update their promotional material! I went ahead and added the iZak back in, making a point to mention that the most current version of the firmware now supports Ogg Vorbis and linking to their FAQ as evidence. [[User:Saxifrage|Saxifrage]] 02:36, 5 May 2005 (PDT)

:Splendid. I didn't want to just stick it back after it had been taken out.--[[User:Ipl|Ipl]] 05:14, 5 May 2005 (PDT)

== Entempo Spirit ==

This inexpensive player from Entempo had listed Vorbis as a "Supported Audio Format", but the device will not index the Vorbis files into it's menus -- let alone play the files. Tested with both the stock and most recent firmware, May 29, 2005. Vendor had been contacted and removed Vorbis support claims from their website, but has not provided any resolution to customers which purchased the product expecting this support. The company's webpage has disappeared as of Feb 2006.

== Lexar LDP-800 dropped ==
It seems that Lexar have abondoned the LDP-800. The following was posted by a user on [http://www.dapreview.net/comment.php?comment.news.1055 dapreview.net]
" Unfortunately, lexar will not offer the LDP-800, but will focus instead
on its existing LDP Players that already offer appealing features and
benefits to meet a variety of consumer needs."
Shame.--[[User:Ipl|Ipl]] 06:15, 22 Jul 2005 (PDT)

There's more info on that dapreview thread that indicates some confusion within Lexar. Currently, it looks like the release is going to happen in early September.

Update 2005-11-11: after inquiries to Lexar's "new products" personnel, I received a telephone message that the LDP-800 will definitely "is not going to see the light of day." Ask me if you want details. I agree that it's a shame since this looked to be an outstanding product. --[[User:dfavro|dfavro]]

== Hong Kong Dream-tech Electronic DT-202, works? please confirm ==
http://hkdream-tech.com
An ebay seller says that it can reproduce Vorbis. This is unconfirmed. In the manufacturer web it says: MP3, WMA, WAV, DMV and etc.

Some webpage also says that it works on Windows, Mac and Linux. Also unconfirmed.
Further investigation required.

== Trekstor i.Beat Cube ==
This player seems to be very similar to the Samsung Yepp YP-T6, possibly with the [[#Yepp_MT-6X|same problems]] regarding Vorbis playback. Trekstor has moved [http://www.trekstor.de/en/produkte/mp3-player/ibeat-cube.html info about this player] from "MP3-Player" to the "Archive" section which propably means that it is not produced anymore.

== The Muzio jm300 / jm-300 does NOT play Vorbis ==

NB this is the jm-300 (not 100 or 200)

I bought this a month ago. I've been unable to play Vorbis files on
it. It simply shows these as 'etc' files and skips over them.

Pitty really, this was the main reason I chose this player.

I've seen lots of discussion about the muzio playing oggs, is there
anybody there who owns a jm300 and is actually playing oggs ? I can't
help think I've juts missed something basic.

== Layout of the PortablePlayers list and Feature matrix ==
It's gone! I've moved this discussion to [[Talk:PortablePlayersv2]]. [[User:Imalone|Imalone]] 10:55, 18 November 2006 (PST)

:Is there something very wrong with those proposals? I mean, is there any reason why (even a simple) feature matrix just could not be applied right now? It would probably solve 'list of top 5 players' problem above too. Just list something basic from the main features, name, size, weight, price, battery (internal, aa, aaa, ..), capasity, flash card type (sd, microsd, ..) , availability (current or discontinued), supported formats, charging (usb or propietary or none). Link to the longer comments. No complicated sorting or anything too fancy. No icons. Name can be a abbreviation to save space, use it as a link to current comments.

::As of now I consider this as '''done'''. --[[User:Gsauthof|Gsauthof]] 10:14, 30 September 2011 (PDT)

== NEXBlack out ==

I got my NEXBlack player today from Frontier Labs. It is a nice gadget with sleek design. They have corrected the occasional snap-sounds that came between tracks and it is overall more usable now. Vorbis-files also play fine, but the current firmware doesn't have Vorbis-tag reader, which is somewhat major drawback. The music selection works through mp3-tags and you can select by album, artist, genre and playlist, but since Vorbis tags won't work you have to select "unordered" to play them. Vorbis-files are all listed in one big list. I hope they either implement a Vorbis-tag reader or revert to old Nex IIe system where you could select by folder in the flash disc. But for the cheap price ($89), it is a good player... waiting for a new firmware..

== Sumvision M18/S1 ==

I've just got the 2GB Sumvision and it plays the OGG files I've tested so far. Should I add it to the list? [[User:Steevc|Steevc]] 04:05, 19 April 2007 (PDT)
:Yes, [http://en.wikipedia.org/wiki/Wikipedia:Be_bold just do it :)]. --[[User:Gsauthof|Gsauthof]] 10:18, 30 September 2011 (PDT)

== Humble A2 Review ==

Just a blog link [http://www.personal.psu.edu/gsc127/blogs/2007/10/happiness-with-cowon-a2.html to my review of the the Cowon A2]. Thanks, [[User:GChriss|GChriss]] 13:23, 6 November 2007 (PST)

== iRiver e100 ==

[http://reviews.cnet.com/4566-6490_7-0.html?filter=1000036_5260177_ CNet] and [http://www.amazon.com/iRiver-E100-Multimedia-Player-White/dp/B00171UYYS/ref=pd_bbs_sr_5?ie=UTF8&s=electronics&qid=1208253617&sr=8-5 Amazon] are saying the iRiver e100 supports Vorbis. I haven't tested it myself. [[User:Mattflaschen|Mattflaschen]] 03:09, 15 April 2008 (PDT)

== Bought an vorbis-enabled player recently? Tell us where! ==

I have started a page that should allow people easier purchasing of vorbis-enabled players: [[PortablePlayers_per_Place]]

Everyone, who bought an vorbis-enabled player recently should update the page with place and model.

== Move Flash/HD-sections to dedicated pages ==

Hi,

IMHO the PortablePlayers page is too long. I want to split it into several pages for each main section. Like [[PortablePlayers/Flash]], [[PortablePlayers/Harddisk]] etc.. Sure, one have to fix some links then, but I am convinced this step would increase the usability a lot.
What do you think about that? --[[User:Gsauthof|Gsauthof]] 01:20, 31 March 2009 (PDT)

:Since there were no objections I restructured the page as planned. --[[User:Gsauthof|Gsauthof]] 10:07, 27 June 2010 (UTC)

VorbisCasts

2011-10-26T16:42:36Z

Martin.leese: Reverted edits by Martin.leese (talk) to last revision by Gsauthof

These links usually point to the page with instructions on how to subscribe to an audiocast (also known as [http://en.wikipedia.org/wiki/Podcast netcast or podcast]), not to the audiocast's main homepage. We don't link directly to the feed url because they tend to move around, because the audiocasts like having people visit their websites, and this way you can compare Vorbis with the other legacy proprietary codecs many of these audiocasts still use.

== Active ==
* [http://alternativlos.org/ Alternativlos] - German audiocast about political topics, social/technical debates and conspiracy theories
* [http://deimhart.net/ Deimhart] - German language audiocast about Linux, Ubuntu and Open Source which got a European Podcast Award in 2011.
* [http://pipes.yahoo.com/pipes/pipe.info?_id=_BR1WkSS3RGuRqdV1L3fcQ FLOSS Weekly] - weekly audiocast from the TWIT network about Free/Libre/Open Source Software
* [http://faif.us/ Free as in Freedom] - Legal aspects of free software by the hosts of the discontinued Software Freedom Law Center audiocast
* [http://www.hackerfunk.ch/ Hackerfunk] - Swiss German audiocast about hacking related topics (vintage computing, programming languages etc.)
* [http://kernelpanicoggcast.net/ Kernelpanic Oggcast]
* [http://sixgun.org/linuxoutlaws/ Linux Outlaws] - Weekly audiocast about releases, news (including MS and Apple watch), interviews and reviews.
* [http://www.radionz.co.nz/national/programmes Radio New Zealand National] - [http://en.wikipedia.org/wiki/Radio_New_Zealand_National publicly-funded non-commercial radio] that provides several audiocasts of its programmes, e.g.: [http://www.radionz.co.nz/national/programmes/ourchangingworld Our Changing World] (science show) and [http://www.radionz.co.nz/national/programmes/atthemovies At the Movies] (movie show)
* [http://blog.radiotux.de/podcasts/ Radio Tux] - Audiocasts from the german Linux news radio
* [http://ratholeradio.org/ Rathole Radio] - Free music audiocast, i.e. mainly featuring music licensed under the Creative Commons license
* [http://www.sourcetrunk.com/ Sourcetrunk] - Project/task centric audiocast using Open Source and free software.
* [http://tllts.org/rsspage.php The Linux Link Tech Show]
* [http://www.tuxradar.com/podcast TuxRadar] - Weekly audiocast about Linux related news, releases and opinionated discussions.

== Directories ==

* [https://wiki.ubuntu.com/Podcasts Ubuntu Podcasts] - List of Linux/Ubuntu related audiocasts including ogg vorbis feeds
* [http://oggcastplanet.org/members.html Oggcast Planet] - List of Ogg Vorbis only audiocasts

== Finished ==
Audiocasts that are still available but do not produce new episodes.

* [http://www.scienceschool.usyd.edu.au/ISS2007/index.php?page=podcasts ISS2007 ecoscience] - lecture audiocast of the 34th International Science School ecoscience, 2007, University of Sydney, Australia. Target audience is high-school students.
* [http://www.pbs.org/cringely/nerdtv/rss/ NerdTV] - Interview audiocast with famous guests from computer/internet history (e.g. the 'inventor of TCP'). Sponsored bei PBS. Until 2006-04.
* [http://www.softwarefreedom.org/feeds/ Oggcast] - Bi-weekly audiocast from the Software Freedom Law Center, New York. Until 2011-08.
* [http://www.linux-foundation.org/weblogs/openvoices Open Voices] - Interview audiocast by the Linux Foundation, featuring interviews with guests like Linus Torvalds, open source people from Mozilla etc.
* [http://jamespurser.com.au/blog/almost-six-years-ago-i-started-linux-australia-update Linux Australia Update]. Until 2006.
* [http://www.archive.org/search.php?query=creator:%22chess%20griffin%22&usort=date Linux Reality Podcast]. [http://www.linuxreality.com/ Until 2008-03.]
* [http://www.lugradio.org/ LugRadio] - Until 2008.

VorbisCasts

2011-10-26T16:40:51Z

Martin.leese: Undo revision 13100 by Gsauthof (talk) SPAM link

These links usually point to the page with instructions on how to subscribe to an audiocast (also known as [http://en.wikipedia.org/wiki/Podcast netcast or podcast]), not to the audiocast's main homepage. We don't link directly to the feed url because they tend to move around, because the audiocasts like having people visit their websites, and this way you can compare Vorbis with the other legacy proprietary codecs many of these audiocasts still use.

== Active ==
* [http://deimhart.net/ Deimhart] - German language audiocast about Linux, Ubuntu and Open Source which got a European Podcast Award in 2011.
* [http://pipes.yahoo.com/pipes/pipe.info?_id=_BR1WkSS3RGuRqdV1L3fcQ FLOSS Weekly] - weekly audiocast from the TWIT network about Free/Libre/Open Source Software
* [http://faif.us/ Free as in Freedom] - Legal aspects of free software by the hosts of the discontinued Software Freedom Law Center audiocast
* [http://www.hackerfunk.ch/ Hackerfunk] - Swiss German audiocast about hacking related topics (vintage computing, programming languages etc.)
* [http://kernelpanicoggcast.net/ Kernelpanic Oggcast]
* [http://sixgun.org/linuxoutlaws/ Linux Outlaws] - Weekly audiocast about releases, news (including MS and Apple watch), interviews and reviews.
* [http://www.radionz.co.nz/national/programmes Radio New Zealand National] - [http://en.wikipedia.org/wiki/Radio_New_Zealand_National publicly-funded non-commercial radio] that provides several audiocasts of its programmes, e.g.: [http://www.radionz.co.nz/national/programmes/ourchangingworld Our Changing World] (science show) and [http://www.radionz.co.nz/national/programmes/atthemovies At the Movies] (movie show)
* [http://blog.radiotux.de/podcasts/ Radio Tux] - Audiocasts from the german Linux news radio
* [http://ratholeradio.org/ Rathole Radio] - Free music audiocast, i.e. mainly featuring music licensed under the Creative Commons license
* [http://www.sourcetrunk.com/ Sourcetrunk] - Project/task centric audiocast using Open Source and free software.
* [http://tllts.org/rsspage.php The Linux Link Tech Show]
* [http://www.tuxradar.com/podcast TuxRadar] - Weekly audiocast about Linux related news, releases and opinionated discussions.

== Directories ==

* [https://wiki.ubuntu.com/Podcasts Ubuntu Podcasts] - List of Linux/Ubuntu related audiocasts including ogg vorbis feeds
* [http://oggcastplanet.org/members.html Oggcast Planet] - List of Ogg Vorbis only audiocasts

== Finished ==
Audiocasts that are still available but do not produce new episodes.

* [http://www.scienceschool.usyd.edu.au/ISS2007/index.php?page=podcasts ISS2007 ecoscience] - lecture audiocast of the 34th International Science School ecoscience, 2007, University of Sydney, Australia. Target audience is high-school students.
* [http://www.pbs.org/cringely/nerdtv/rss/ NerdTV] - Interview audiocast with famous guests from computer/internet history (e.g. the 'inventor of TCP'). Sponsored bei PBS. Until 2006-04.
* [http://www.softwarefreedom.org/feeds/ Oggcast] - Bi-weekly audiocast from the Software Freedom Law Center, New York. Until 2011-08.
* [http://www.linux-foundation.org/weblogs/openvoices Open Voices] - Interview audiocast by the Linux Foundation, featuring interviews with guests like Linus Torvalds, open source people from Mozilla etc.
* [http://jamespurser.com.au/blog/almost-six-years-ago-i-started-linux-australia-update Linux Australia Update]. Until 2006.
* [http://www.archive.org/search.php?query=creator:%22chess%20griffin%22&usort=date Linux Reality Podcast]. [http://www.linuxreality.com/ Until 2008-03.]
* [http://www.lugradio.org/ LugRadio] - Until 2008.

MediaWiki:Deletereason-dropdown

2011-09-15T19:57:47Z

Martin.leese: Added "SPAM links" + reordered

* Common delete reasons
** SPAM links
** Vandalism
** Copyright violation
** Author request

Bounties

2011-09-13T16:05:25Z

Martin.leese: Reverted SPAM link

These are proposed bounty projects, similar to http://gnome.org/bounties/
or the [http://ghostscript.com/article/58.html Ghostscript bug bounty] program.
We don't have the same level of funding but could start a pot with $10-$100 and
let people contribute to specific bounties through paypal.

=== Xiph Quicktime Plugin ===
[http://www.xiph.org/quicktime/ QuickTime Components] is now a project hosted on xiph.org.

You have to write a Quicktime Plugin for the Ogg container and the Xiph Codec Family.
[http://qtcomponents.sf.net qtcomponents] provides support for Ogg Vorbis and MNG. This could be used as start.
Xiph Quicktime Plugin has to support encoding/decoding for:
* Ogg Media container
**[http://qtcomponents.sf.net qtcomponents] ''has an operational pluggable API for import, it needs some work to be long term supportable. It does not have a pluggable API for exporting at this time.''
* Support for Chained Ogg Streams
**[http://qtcomponents.sf.net qtcomponents] ''imports chained files as multiple tracks in QuickTime. It does not create chained files during export.''
* Support for Icecast Streams (sending is optional)
**[http://qtcomponents.sf.net qtcomponents] ''implements nothing towards this item. First up is a reverse-engineering effort, as the specifications for a streaming media handler have not been published.''
* Support for Xiph Codec Family: Vorbis, Theora, FLAC, Speex, Writ
**[http://qtcomponents.sf.net qtcomponents] ''has code for Vorbis and Speex (not working at the moment) and there is code at [http://damien.drix.free.fr/qtflac/ Damien Drix's site] for FLAC (decode only).''
It must also be possible to use the Xiph codecs in .mov files in combination with other quicktime codecs.
*[http://qtcomponents.sf.net qtcomponents] ''supports embedding media encoded with Xiph codes into .mov files.''
The plugin should work with at least QuickTime 6.x and 7.x on Mac OS X and Windows. (Mac OS 9 would be nice but probably isn't as important.)

All work must be released under the GPL.

Proposed bounty: 100€

=== Aggressive low-bitrate libvorbis encoding improvements for Vorbis I ===
libvorbis has a lot of room for improvement in all quality/bitrate departments, particularly at the lower quality levels / bitrates. There are many directions from which to approach this problem.

To claim this bounty, the following criteria would have to be met:
* A 25%-or-better reduction in bitrate for quality levels -1, 0, 1 on a reasonable testsuite while maintaining qualitative equivilence (or improvement) in community testing.
* No overall qualitative/bitrate regressions in quality levels 2 upwards
* Output ogg files compatible with Vorbis I spec
* Changes under suitable license for re-integration with Xiph.Org libvorbis

Proposed bounty: 200€

=== iPod playback support ===
The [http://ipodlinux.sourceforge.net/ Linux on iPod] project has vorbis decode working (with alternate firmware) at a good fraction of realtime. It should be a small matter of optimization to get it working
for useful playback.

Proposed bounty: 100€

=== Ogg Vorbis Bitrate Peeling ===
:Note: a bounty for this project has been posted on [https://launchpad.net/ launchpad.net]: [https://launchpad.net/bounties/ogg-vorbis-bitrate-peeling Add bitrate peeling to the standard libvorbis encoding library].
Ogg Vorbis bitrate peeling has been a topic brought up time and again to combat MP3 enthusiasts. But this feature does not actually exist, only the mere possibility abounds. This bounty is set to change that.
The peeler must meet the following criteria:
* Any Vorbis stream can be converted (not transcoded) to a lower quality setting
* Resulting streams would be identical or nearly identical to a stream generated by encoding the original source to the selected quality
* This process is reasonably fast (that is, signifigantly faster than re-encoding from source)
The following must also be accomplished to claim this bounty:
* The encoding libraries must be updated to create peelable Vorbis streams natively
* Old Vorbis streams must be peelable already, or convertable with a utility in order to be made peelable
* If older streams are not natively peelable, old unpeelable Vorbis streams must be identifiable and discernable from peelable streams in such a way as to facilitate transcoding streams from the old format
* All work submitted must be licenced under a BSD style licence (excepting circumstances where other licences may conflict)

Proposed bounty: 100€

XSPF

2011-08-26T01:47:29Z

Martin.leese: /* Supporting applications */ Fixed messed up link + tidy

'''XML Shareable Playlist Format''' ('''XSPF'''), pronounced "spiff", is a next-generation [http://en.wikipedia.org/wiki/playlist playlist] format for digital media such as songs in Vorbis or MP3 format. This wiki is for developers.

The mime type for XSPF playlists is <tt>application/xspf+xml</tt>.

Spec is at http://www.xspf.org/specs/

== Supporting applications ==

These are applications which support XSPF and have not yet been added to the [http://xspf.org/applications main applications list]:

* [http://www.jamendo.com/ Jamendo]
** You have to be a member and to select "XSPF" in your preferences to use them by default, but you can look and test a sample playlist here: http://www.jamendo.com/get/track/id/album/audio/xspf/1003/?aue=ogg2

* http://www.ArtistServer.com
** on artist profile pages http://www.artistserver.com/bliss
** on stations and playlists http://www.artistserver.com/stations/
** on genre pages http://www.artistserver.com/DownTempo

* Project Opus http://projectopus.com
** see http://www.projectopus.com/new-player for details
** includes modified version of Fabricio's player
<blockquote>
"We added: A Scrubber/Shuttle so the lister can move the playhead to any point along the song. Time Remaining, Elapsed Time Played, Genre of Song, Origin/Location (city) of artist. Site specific stuff which my not be of interest to others is: Review song link: we were adding as a layer to the player but, it got too large and ugly. Buy song link. And a bunch of nice styling/skin tweaks."
</blockquote>

* trend of XSLT for xspf to html example
** http://dokerlund.edhsweb.org/wordpress/archives/23 is announce
** http://dokerlund.edhsweb.org/wordpress/xspf/media/playlist.xml is in practice

* Zuardi player modified to support FLV and SWF as well as mp3: http://blitz-xplore.blogspot.com/2006/05/file-xspfplayer.html

== Limited supporting applications ==
* foo_xspf - writes xspf files only with location. So the goal of playlist sharing between friends is not achieved.
* [http://roaraudio.keep-cool.org/rpld.html RoarAudio PlayList Daemon] - no read support yet.

== Non supporting applications listed as supporting ==
* http://php4xspf.berlios.de/ - From their page: Note: The classes are stil in alpha and do not incorporate ... even the possibility to parse a XSPF file.

== See also ==

* [[XSPF FAQ]]
* [[XSPF v1 Notes and Errata]]
* '''[[XSPF Year 2009]]'''
* [[XSPF Conformance Tests]]
* [[XSPF Wish List]]
* [[XSPF Examples in the wild]]
* [[List of known XSPF extensions]]
* [[List of known XSPF metas]]
* [[JSPF Draft|JSPF]] (''JSON Sharable Playlist Format'' a.k.a. ''XSPF on JSON'')

== External links ==

* [http://xspf.org/xspf-v1.html XSPF specification]
* [http://validator.xspf.org/ Online XSPF Validator]
* [https://trac.xiph.org/browser/websites/xspf.org/images/banners "Valid XSPF" button]
* [https://trac.xiph.org/browser/trunk/xspf/ Source control for source code, spec, XSLT, validation]
* [https://trac.xiph.org/browser/websites/xspf.org/ Source control for XSPF.org website]
* [http://downloads.xiph.org/releases/xspf/ XSPF-related releases]
* [http://gonze.com/playlists/playlist-format-survey.html A survey of playlist formats], by Lucas Gonze
* [http://en.wikipedia.org/wiki/XSPF XSPF Reference page on Wikipedia]
* [http://web.archive.org/web/20060410160006/http://playlist.musicbrainz.org/playlist/moin.cgi/ Old XSPF wiki]

[[Category:XSPF]]

Ambisonics

2011-04-09T23:10:20Z

Martin.leese: Fixed broken links (two left)

This page is part of the XiphWiki, and is aimed at people developing file
formats and associated software for Ambisonics. For an general introduction
to Ambisonics, please go to the

[[Wikipedia:Ambisonics|Wikipedia page on Ambisonics]].

'''Ambisonics''' is a surround sound system first developed in the 1970s.
Its main difference from other surround techniques is that it separates
transmission channels from speaker feeds, the speaker feeds being derived
using a decoder situated in the living room. Decoders can be implemented
in either hardware or software. Typically more speakers are used than
transmission channels, and the more speakers used then the more stable the
resulting soundfield. Speakers can be arranged in a number of configurations,
regular polygons being the most popular.

Ambisonic files can come in a number of different formats. The main one is
called B-Format, the other formats being derived from this. UHJ format is
mono- and stereo-compatible. G-Format is a set of speaker feeds, so can be
enjoyed in surround sound without the need for a decoder in the living room.

== Ambisonics and 5.1 ==

Ambisonics and conventional 5.1 surround sound are very different. 5.1 is a
set speaker feeds, the signal only being fully defined for sounds coming
from a speaker. Phantom images between speakers can be created, but the
technique to do so is left unspecified. Many 5.1 releases use pair-wise
mixing to create phantom images. This is understandable as almost all
stereo recordings are mixed using pair-wise mixing.

Pair-wise mixing is also called "pan-potting", "amplitude mixing" and
"intensity stereophony". It mixes signals into the feeds for a pair of
speakers to create the illusion that a sound is coming from a point
somewhere between the speakers. During mixing, the apparent location of
each sound is determined only by the relative amplitude of that sound in
the two speakers.

Unfortunately, pair-wise mixing works poorly when the speakers are to the
rear of the listener and not-at-all when they are to one side. You can
demonstrate this for yourself by performing
[http://members.tripod.com/martin_leese/Ambisonic/exper.html a very simple experiment].
Pair-wise mixing did not work in the quadraphonic era and it will not work
now. Such an absolute statement can be made because the way that humans
localise sound has not changed.

Ambisonics is fundamentally different from 5.1. What is encoded in
Ambisonics is not speaker feeds, but ''direction''. When mixing in
Ambisonics, the positions of the speakers are unknown
''and are of no interest''. Further, when Ambisonics is decoded to speaker
feeds all of the speakers cooperate to localise a sound in its correct
position so, for example, when the speakers on the left push those on the
right pull. The speakers all contribute to the creation of a single
coherent soundfield.

=== Ambisonics to 5.1 ===
Converting Ambisonics to 5.1 is straightforward, and is discussed below
(see [[#G-Format|G-Format]]).

=== 5.1 to Ambisonics ===
Converting 5.1 to Ambisonics is more difficult. It is easy to make the
five speaker feeds phantom images, called "virtual speakers". (The ".1"
channel can be folded into W.) The problem with this is that even if the
Ambisonic rendering is perfect, the result will only be as good as the
original 5.1 played through ''real'' speakers. It will not be an
improvement. Nobody has yet come up with a way for Ambisonics to improve
5.1; 5.1 is simply too broken.

== B-Format ==

B-Format is a single coherent soundfield composed of a set of related
channels. The number of channels used depends on whether the soundfiled
is horizontal-only or full-sphere, and on the order. These B-Format
channels are transmission channels, not speaker feeds. Listening to
B-Format requires a decoder in your living room. Some numbers of
channels are tabulated below.

=== Channel correlation ===
Compression techniques typically make use of channel correlation to
remove redundancy from the audio data, and so improve the compression
ratio.

The correlation between B-Format channels depends on the content.
Four-channel B-Format consists of an
omni-directional component, called W, and three figure-of-eight
components pointing forward, left and up, called X, Y, Z.
([http://members.tripod.com/martin_leese/Ambisonic/Harmonic.html Pictures are available].)
Three-channel, horizontal-only B-Format simply omits the Z channel. This
means that anything in X also appears in W. Same for Y and Z. (W is
omni-directional; everything appears in W.) Also, if content comes from
Front-Left then it appears equally in X and Y. Same for content from
Front-Right, Back-Left, Back-Right; only the relative polarities change.
So there can be a lot of correlation between B-Format channels, but it is
content dependent.

One problem with B-Format is that it is big on low-frequency phase. The
phase relationships between the different B-Format channels are important
if the resulting soundfield is to correctly "gel". This may be a problem
when B-Format channels are compressed using lossy compression.

There is a file specification in use for downloadable B-Format files
called the
[http://members.tripod.com/martin_leese/Ambisonic/B-Format_file_format.html ".amb" specification].

=== Limitations of the ".amb" specification ===
The [http://members.tripod.com/martin_leese/Ambisonic/B-Format_file_format.html ".amb" specification]
for downloadable B-Format files is based on the WAVE-EX format. There are
currently over 200 pieces available in this format
[http://www.ambisonia.com for free download]. Most of these are
first-order full-sphere soundfields. (The same website also has details of
[http://www.ambisonia.com/wiki/index.php/Playback_Software ad hoc software decoders].)
Some of the limitations of the specification are:

#It is limited to 4 GByte files (2 GBytes if somebody screwed up).
#It is limited to third-order soundfields and below. While third-order looks like a lot (16 channels), there already exists a prototype mic that can record up to fourth-order (25 channels).
#No compression (particularly lossless).

The reason that the ".amb" file specification is limited to third-order
and below is because it uses the number of channels to uniquely define the
soundfield order. Unfortunately this simple and elegant scheme does not
work above third-order as ambiguities creep in. (One ambiguity is
illustrated in the table below.)

A more general file format will have to use something else, such as
''Malham notation'', or storing both the horizontal-order and
height-order. There is a one-to-one correspondence between Malham notation
and the pair of orders, and either can generate the number of channels.

==== Malham notation ====
Malham notation specifies the order of a B-Format soundfield using a
string of characters, each character being either '''f''' (for full-sphere)
or '''h''' (for horizontal). The first character in the string specifies
the type of the first-order components, the second character the type of
the second-order components, etc.

{| class="wikitable" style="text-align:center"
|
|-
!Horizontal order
!Height order
!Soundfield_type
!Malham notation
!Number of_channels
!Channels
|-
| 1|| 0||horizontal||'''h'''|| 3||WXY
|-
| 1|| 1||full-sphere||'''f'''|| 4||WXYZ
|-
| 2|| 0||horizontal||'''hh'''|| 5||WXYUV
|-
| 2|| 1||mixed-order||'''fh'''|| 6||WXYZUV
|-
| 2|| 2||full-sphere||'''ff'''|| 9||WXYZRSTUV
|-
| 3|| 0||horizontal||'''hhh'''|| 7||WXYUVPQ
|-
| 3|| 1||mixed-order||'''fhh'''|| 8||WXYZUVPQ
|-
| 3|| 2||mixed-order||'''ffh'''|| 11||WXYZRSTUVPQ
|-
| 3|| 3||full-sphere||'''fff'''|| 16||WXYZRSTUVKLMNOPQ
|-
| 4|| 0||horizontal||'''hhhh'''|| 9||extra channels unlabled
|}

=== Default channel conversions from B-Format ===
Converting a B-Format file to a mono file is straightforward. Use Mono =
W*sqrt(2).

Converting a B-Format file to a stereo file is more difficult. The "proper"
way to do this is to convert the W,X,Y channels to two-channel UHJ.
Unfortunately this requires the use of wide-band 90-degree phase shifters.
In the digital domain these are usually implemented as convolution filters.

Assuming 90-degree phase shifters are unavailable then the problem is one of
choice. Starting from B-Format, it is possible to synthesize ''any'' mic
response pointing in ''any'' direction. Hence, it is possible to synthesize
''all'' coincident stereo mic techniques. Two popular stereo techniques are
''Blumlein Mid-Side'' and ''Blumlein Crossed Pair''.

==== Blumlein Mid-Side ====
<pre>
Mid = (W*sqrt(2)) + X /*This is a cardioid response pointing forward*/
Left = Mid + Y
Right = Mid - Y
</pre>

==== Blumlein Crossed Pair ====
<pre>
Left = (X + Y)/sqrt(2) /* (Left, Right) are just the (Y, X) */
Right = (X - Y)/sqrt(2) /* responses rotated by -45 degrees */
</pre>

Which conversion to stereo is better depends on the material and how it was
recorded. A good suggestion is to not specify a ''particular'' default
channel conversion; instead, simply specify that there must be one. If one
has to be specified then Blumlein Crossed Pair is the simpler.

== UHJ format ==

B-Format is the main format for Ambisonic files. However, B-Format is
not mono- or stereo-compatible. This is why the UHJ hierarchical system
was developed. Depending on the number of channels available, the UHJ
system can carry more or less information, but at all times it is fully
mono- and stereo-compatible. Up to four channels (Left, Right, T, Q) may
be used. The T-channel can also be band-limited but, as this
"2½-channel UHJ" was only ever used for FM radio transmission, it
will not be discussed further.

To listen to UHJ files in surround requires a decoder in your living room.
Also, UHJ is restricted to first-order soundfields, either horizontal (two-
and three-channel UHJ) or full-sphere (four-channel UHJ).

Converting B-Format channels to UHJ channels, and vice versa, requires the
use of wide-band 90-degree phase shifters. In the digital domain these
are usually implemented as convolution filters. Conversion between
four-channel B-Format (W, X, Y, Z) and four-channel UHJ (Left, Right, T,
Q) can be accomplished without loss of information. The same with
three-channel to three-channel (W, X, Y) <=> (Left, Right, T). It is
possible to recover three-channel B-Format (W, X, Y) from two-channel UHJ
(Left, Right), but not without loss. It is also important for the Ambisonic
decoder to be aware that the B-Format channels were recovered from
two-channel UHJ (because of the need to apply different shelf filters).

Several hundred
[http://members.cox.net/surround/uhjdisc/ambindex.htm two-channel UHJ LPs and CDs]
have been released. Three- and four-channel UHJ recordings have never been
commercially released.

=== UHJ encoding and decoding equations ===

==== Encoding ====
<pre>
S = 0.9396926*W + 0.1855740*X
D = j(-0.3420201*W + 0.5098604*X) + 0.6554516*Y

Left = (S + D)/2.0
Right = (S - D)/2.0
T = j(-0.1432*W + 0.6512*X) - 0.7071*Y
Q = 0.9772*Z

where j is a +90 degree phase shift
</pre>

==== Decoding ====
For two-channel UHJ:
<pre>
S = (Left + Right)/2.0
D = (Left - Right)/2.0

W = 0.982*S + j*0.164*D
X = 0.419*S - j*0.828*D
Y = 0.763*D + j*0.385*S

where j is a +90 degree phase shift
</pre>
Note that two-channel UHJ requires the player to use different shelf filters than for B-Format.

For three- and four-channel UHJ:
<pre>
S = (Left + Right)/2.0
D = (Left - Right)/2.0

W = 0.982*S + j*0.197(0.828*D + 0.768*T)
X = 0.419*S - j(0.828*D + 0.768*T)
Y = 0.796*D - 0.676*T + j*0.187*S
Z = 1.023*Q

where j is a +90 degree phase shift
</pre>

There is a file specification for downloadable two-channel UHJ files
called the
[http://members.tripod.com/martin_leese/Ambisonic/UHJ_file_format.html ".uhj" specification], but it is not currently in use.

=== Limitations of the ".uhj" specification ===
The [http://members.tripod.com/martin_leese/Ambisonic/UHJ_file_format.html ".uhj" specification]
for downloadable two-channel UHJ files is based on the WAVE or WAVE-EX
format. A UHJ chunk is added to the file to indicate it is UHJ. As
unrecognized chunks are always skipped, use of this chunk maintains stereo
compatibility. Some of the limitations of the specification are:

#It is limited to 4 GByte files (2 GBytes if somebody screwed up).
#It is limited to two-channel UHJ files. Three- and four-channel UHJ are not accommodated.
#No compression.

The ".uhj" spcecification is only defined for two-channel UHJ to maintain
stereo compatibility. While it would be possible to add the UHJ chunk to
three- and four-channel WAVE-EX files, the recommendations from Microsoft
for playing such files is that the audio device should render the extra
channels to output ports not in use. This can happen even when the extra
channels are masked off. (Put simply, in WAVE-EX files the channel mask
does ''not'' mask channels.) Because of this, three- and four-channel
WAVE-EX files can not be made stereo compatible.

In the Xiph world, it should be possible to use default channel conversions
to ensure that three- and four-channel UHJ files remain stereo compatible.

=== Default channel conversions from UHJ ===
Converting a UHJ file to a mono file is straightforward. Use Mono =
(Left + Right) / sqrt(2).

Converting a UHJ file to a stereo file is even easier. Use Left = Left, Right = Right, and discard T and Q if present.

== G-Format ==

A G-Format file is any common multi-channel surround file containing an
Ambisonic soundfield pre-decoded to its speaker feeds. This allows
listeners who do not own an Ambisonic decoder to enjoy Ambisonics.

The sound engineer creates a set of speaker feeds for a particular number
and arrangement of speakers. This is typically four speakers arranged in
a square. Other speaker arrangements are also possible

In Ambisonics, all speakers cooperate to localise sounds in any particular
direction; there are no "surround speakers" as such. Because of this, best
results when playing G-Format recordings (and Ambisonics in general) are
obtained when the speakers are matched. The easiest way to accomplish this
is to use identical speakers. Unfortunately, many home theatre systems
include a centre-front speaker which is different from the other speakers.

An easy way to cope with this is adopted on G-Format recordings commercially
released on DVD-A by [http://www.wyastone.co.uk/nrl/dvd.html Nimbus Records].
They use four speakers in a square, the centre-front speaker being unused.

=== Recovering B-Format from G-Format ===
It is sometimes possible to recover the original B-Format channels from
the G-Format speaker feeds. The recovered B-Format channels can then be
fed to a decoder in the listener's living room, and so accommodate a
speaker arrangement different from the one used when the G-Format file
was produced. Each B-Format channel is recovered using a weighted
combination of the speaker feeds in the G-Format file. The conversion
coefficients required for the B-Format recovery depend on the particular
speaker arrangment chosen by the sound engineer. (Obviously, if a
B-Format version of the file also exists then it can be fed to the
decoder directly without the need for G-Format.)

File formats for G-Format include all multi-channel formats that contain
speaker feeds. However, these will not contain information to allow the
B-Format channels to be automatically recovered. A [http://members.tripod.com/martin_leese/Ambisonic/G-Format_chunk.html ".amg" file format]
(based on WAVE-EX) for downloadable G-Format files, which will allow
the B-Format channels to be automatically recovered, has been proposed.
Such file formats have the advantage of storing the conversion
coefficients at the time the G-Format file is created. This is the only
time the required information is readily available.

=== Default channel conversions from G-Format ===
Converting a G-Format file to a mono or stereo file is straightforward.
First, recover the B-Format channels using the conversion coefficients
contained in the file. Second, follow the advice given above for
[[#Default channel conversions from B-Format|Default channel conversions from B-Format]].

== Resources on Ambisonics ==

*There is a set of [http://en.wikipedia.org/wiki/Ambisonics Wikipedia articles on Ambisonics].
*Of particular relevance is the [http://members.tripod.com/martin_leese/Ambisonic/B-Format_file_format.html ".amb" specification] in use for downloadable B-Format files. However the ".amb" spec has some limitations which it would be useful to overcome.
*There is also the [http://members.tripod.com/martin_leese/Ambisonic/UHJ_file_format.html ".uhj" specification] for downloadable two-channel UHJ files, but it is not currently in use. The ".uhj" spec also has some limitations which it would be useful to overcome.
*[http://members.tripod.com/martin_leese/Ambisonic/ This website] has many pages on Ambisonics (including at the bottom links to other Ambisonic websites).
*[http://www.ambisonic.net/ Ambisonic.Net website] includes a detailed series of descriptive and practical articles on current and past Ambisonic techniques with links to tools, other sites and additional material.
*[http://ambisonic.info/info/ricardo.html Richard Lee's page on Ambisonics] contains articles on shelf filters and the design of Ambisonic decoders.

[[Category:Developers stuff]]

Metadata

2011-01-21T05:25:49Z

Martin.leese: /* VorbisComments */ Added GENRE so list matches that in Ogg Vorbis I format specification

This page aims to give an overview of the current state of metadata in Ogg and the ongoing projects towards improving it. The different components work in concert; for example [[Ogg Skeleton]] provides important infrastructure for [[CMML]], [[VorbisComment]] is simple to use and program, while the draft [[M3F|Multimedia Metadata Format (M3F)]] provides more sophisticated information.

== [[VorbisComment]]s ==

All the Xiph.org codecs have some internal mechanism for including metadata about the current stream.
Generally, this is one of the codec headers, and in the words of the [http://www.xiph.org/vorbis/doc/v-comment.html vorbis spec],
"It is meant for short, text comments ... much like someone jotting a quick note on the bottom of a CDR." A single VorbisComment can store upto 2^64 bytes (16 exabytes).

VorbisComments store metadata describing the stream in key=value pairs, such as "ARTIST=Elvis", "TITLE=Blue Suede Shoes". Multiple copies of any given key are allowed (for example you can specify ARTIST several times for multiple performers). The specification has several suggested keys: TITLE, VERSION, ALBUM, TRACKNUMBER, ARTIST, PERFORMER, COPYRIGHT, LICENSE, ORGANIZATION, DESCRIPTION, GENRE, DATE, LOCATION, CONTACT, ISRC. See the [http://www.xiph.org/vorbis/doc/v-comment.html specification] for the intent of each one.

The [[VorbisComment]] page contains improvements to the suggested comment set.

== [[FLAC]] metadata blocks ==

Metadata is included in the FLAC codec as METADATA_BLOCK_DATA. Seven types of metadata block are defined:
#''METADATA_BLOCK_STREAMINFO'': Sample rate, number of channels, etc.
#''METADATA_BLOCK_PADDING'': Nul padding.
#''METADATA_BLOCK_APPLICATION'': Third-party applications can register an ID. Metadata is typically 32-bit integers, but any datatypes can be specified.
#''METADATA_BLOCK_SEEKTABLE'': For one or more seek points.
#''METADATA_BLOCK_VORBIS_COMMENT'': Also known as FLAC tags, the contents of a VorbisComment packet. Note that the 32-bit field lengths are little-endian coded according to the Vorbis spec, as opposed to the usual big-endian coding of fixed-length integers in the rest of FLAC. FLAC metadata blocks are limited to 2^24 bytes (16 megabytes) and a VorbisComment packet in FLAC must fit within that limit.
#''METADATA_BLOCK_CUESHEET'': Typically, but not necessarily, for CD-DA (Red Book) cuesheets.
#''METADATA_BLOCK_PICTURE'': For binary picture data.

== [[Ogg Skeleton]] ==

[[Ogg Skeleton]] provides metadata useful for handling Ogg streams. This includes information like mime-types and mapping for granulepos which allows seeking streams without the need for the demuxer to understand them. The latest version, [[Ogg Skeleton 4]], also provides a keyframe index to enable faster seeking over high latency networks.

Ogg Skeleton allows for attachment of message header fields, given as name-value pairs, that contain some sort of protocol messages about the logical bitstream. This is intended for decode related stuff, such as the screen size for a video bitstream or the number of channels for an audio bitstream.

== [[CMML]] ==

The [[CMML|Continuous Media Markup Language]] allows time-based marking up of media streams, at its simplest this allows you to divide media files into clips and provide information about each clip.

== [[M3F]] ==

'''[[M3F|Multimedia Metadata Format]]''' for the Ogg container aims to provide metadata for media streams. The exact aims of this project are still under development, but they include being able to describe artist relationships to a piece more accurately as well as providing the structure to encourage more reliable metadata.

The format is intended to replace VorbisComments for the use of ''structured'' metadata, allowing VorbisComments to revert to its orginally intended use of "short, text comments ... much like someone jotting a quick note on the bottom of a CDR."

== [[XMLEmbedding]] ==

To implement XML metadata in Ogg (as for [[M3F]]), a mapping to Ogg streams is needed. The use of XML metadata will also open the way for the inclusion of technologies such as:
* RDF + dublin core
* [http://www.adobe.com/products/xmp/ XMP]
* [http://wiki.musicbrainz.org/MusicBrainzXMLMetaData MusicBrainz]
* [http://www.w3.org/Graphics/SVG/ SVG]

== Aims of advanced metadata ==

VorbisComments work well enough for most things, and can be overloaded/abused (depending on your point of view) for most other things. But there are three major requirements that point to the design of an external metadata format; one that can be interleaved with the other streams in a container.

* '''Machinability:''' There are a number of items of metadata that a player will want to parse and take action on. While there are usually 'convention' schemes for doing this with the embedded comment headers, this is much easier if there is a separate metadata stream designed for such use, instead of having to do best-effort parsing of natural language comments. For example, a video file with multiple audio tracks can specify the language of each one; a player than can parse these reliably can match them against a language preference list configured by the user to automatically select and begin playback of the best option.

* '''Kitchen Sink:''' There are a minority of people who care passionately about having every detail about a track available. In the sense of conserving such information, and providing an equivalent to liner notes for online distribution, this is a goal worth supporting. However, the simple unstructured key-value pairs offered by the inline metadata are unwieldy for this level of detail. How do you tell the 2nd unit Assistant Director from the USA unit Assistant Director? How do you indicate which artist played tenor sax in the solo?

* '''Addressability:''' The internal comment metadata headers are by necessity attached to a single content stream. This is useful for some appication, but a limitation in others. In a multiplexed stream, which set of comments refers to the collection as a whole? (By convention, in Ogg, it's the first logical bitstream occuring, but we can do better.) A separate metadata stream type must address this issue of collective metadata while still allowing description of individual streams. It should also allow temporal addressability, so that changes can be described. Because the in-stream comment metadata are part of the codec headers, it cannot change over the course of the stream, and allowing additional comment packets elsewhere in the stream presents seeking challenges. In the Ogg container this can be resolved by inserting a chain boundary, but this is a poor option for very-low-bitrate streams and unreliable transports such as RTP.

VorbisComment

2011-01-21T05:21:27Z

Martin.leese: /* New RIGHTS field name proposal */ Added comment

VorbisComment is a base-level [[Metadata]] format initially created for use with Ogg [[Vorbis]]. It has since been adopted in the specifications of
[[Ogg]] encapsulations for other Xiph.Org codecs including [[Theora]], [[Speex]] and [[FLAC]].

The use case for VorbisComment is given as:
<blockquote>
... 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.[http://xiph.org/vorbis/doc/v-comment.html]
</blockquote>

VorbisComments are typically used to provide basic information like the title and copyright holder of a work.
As such the scope is similar to that of ID3 tags used with MP3 files.
VorbisComment is widely supported on [[VorbisHardware|portable Ogg Vorbis players]] as well as streaming, editing and playback software.

Although the syntax of VorbisComment is well-specified, various conventions exist for the field names in use.
The goal for this page is to codify best practices and collect proposals for standardization of VorbisComment field names.

VorbisComments are typically encoded as the second packet in a codec stream. When VorbisComments are included in the first (ie. Theora) stream of an Ogg Theora file, they are assumed to cover all streams in the multiplexed group. [http://lists.xiph.org/pipermail/vorbis-dev/2008-December/019676.html]

VorbisComment is the simplest and most widely-supported mechanism for storing metadata with Xiph.Org codecs. For other existing and proposed mechanisms, see [[Metadata]].

== Recommended field names ==

The current [http://xiph.org/vorbis/doc/v-comment.html VorbisComment recommendation] contains a recommended set
of field names for comments.

== Proposed field names ==

Some proposals for extra field names:

* [http://age.hobba.nl/audio/mirroredpages/ogg-tagging.html Ogg Vorbis Comment Field Recommendations]
* [http://gophernet.org/articles/vorbiscomment/ Proposals for extending Ogg Vorbis comments]
* [[Field names]]

Comments are intended to be free-form, but for the purposes of interoperability, it is helpful to define tag sets for particular applications, and provide some guidelines for machine parsing. Note that some field names have to be non-free-form to achieve machine parsing.

=== Cover art ===

==== METADATA_BLOCK_PICTURE ====
The [http://flac.sourceforge.net/format.html#metadata_block_picture binary FLAC picture structure] is base64 encoded and placed within a VorbisComment with the tag name "METADATA_BLOCK_PICTURE". This is the preferred and recommended way of embedding cover art within VorbisComments. It has the following benefits:

* Easy to use for developers since the identical (or similar) structure is also used by FLAC and MP3.
* The cover art can either be linked or embedded within the stream.
* Common picture file formats are supported (jpg and png).
* A description may be included and the picture type (front cover, back cover...) and image mime type are provided.
* Base64 encoded data is invariant under UTF-8 and a valid UTF-8 string, so obeys the rules for comment data.

Implementations interpreting or writing picture blocks should note the following details:

===== General encoding/decoding =====
* Failure to decode a picture block should not prevent playback of the file (failure to deal with the particularly large packet required by the comment header is a separate problem with the player implementation).
* Base64 encoding is used as in section 4 of [http://www.faqs.org/rfcs/rfc4648.html RFC4648]. We note that line feeds are not allowed and padding characters ('=') are required.
* Applications adding picture blocks should inform users that some applications or hardware may not support them and should provide a method to remove the blocks (this is expected to be trivial for applications capable of adding them).

===== Block handling =====
* The unencoded format is that of the [http://flac.sourceforge.net/format.html#metadata_block_picture FLAC picture block]. The fields are stored in big endian order as in FLAC, picture data is stored according to the relevant standard.
* Picture data should be stored in PNG or JPEG formats or linked separately. It is recommended readers support both PNG and JPEG
* Allowed values for the MIME string are "image/", "image/png", "image/jpeg" and "-->" (the link indicator) and "" (length 0). An empty MIME string indicates type "image/"
* Fields present in the ID3V2.4.0 [http://www.id3.org/id3v2.4.0-frames#line-1085 Attached Picture Frame] (APIC Frame) take the same interpretation as in the ID3V2.4.0 format with the following exceptions (following the FLAC format):
** The description field is UTF-8 (encoded without ID3V2's initial 'encoding byte')
** String fields are not null terminated: their preceding length fields are used instead.

===== Linked images =====
Support for linked images is optional for applications handling picture blocks. When a linked picture is indicated the following rules are observed:
* The picture data is a complete URL indicating the picture to be used, relative URLs are allowed (note relative URLs do not start with a protocol specifier and are retrieved with the same protocol as the file being processed).
* Links are ISO-8859-1 encoded
* Applications MAY retrieve linked images via the file:// protocol.
* Applications MUST obtain user approval if they wish to retrieve images via remote protocols.
* Link targets may become unavailable: applications supporting linked images SHOULD recover gracefully from this and MAY report the absence to the user.
* The type of the linked file is not restricted to JPEG and JFIF and applications MAY support other formats
* If the application does not support linked images, the target is unavailable, not permitted or an unknown format the picture block should be skipped.
* Applications may make links available to users, this is of particular use when links are unsupported or of unsupported type

===== Image dimension fields =====
* The height, width, colour depth and 'number of colours' fields are for purely informational purposes. Applications MUST NOT use them for decoding purposes, but MAY display them to the user and MAY use them to make a decision whether to skip the block (for example if selecting the most appropriate among multiple blocks).
* Applications writing picture blocks MUST set these fields correctly OR set them all to zero.

===== Multiple blocks =====
* Multiple image blocks MAY be included as separate METADATA_BLOCK_PICTURE comments.
* There may only be one each of picture type (APIC type) 1 and 2 in a Vorbis stream.
* Block order is significant for some types and applications should preserve the comment order when reading or writing VorbisComment headers. The block order may be used to determine the order pictures are presented to the user.

===== Playback tests =====
Embedding a picture into the file might break playback of existing players (especially hardware players, software players could be updated easily). A workaround would be to link the picture within the tag. Furthermore users should become informed in some way that embedding a picture COULD cause problems (as stated above).

In order to test if there are playback problems, there are test files available [http://www.audioranger.com/coverart_mk.ogg here] and [http://www.audioranger.com/coverart_im.ogg here]. You're invited to download one of these test files (or both), test playback on your software and hardware players, and report the results here on the wiki.

'''Tested software players'''
* Audacious 1.5.1: no problem
* foobar2000: no problems
* Gnome: built-in preview playback: no problem
* MediaMonkey: no problems
* Media Player Classic (unicode build) 6.4.9.1: no problem
* RoarAudio: no problems (server and client side)
* Rythmbox 0.11.6: no problem
* Totem 2.24.3: no problem
* VLC 0.9.4/0.9.6: doesn't play
** Patch send to VLC to fix this - should get in 1.0.0
* WinAmp: no problems
* Windows Media Player 11: no problem
* XMPlay 3.4.2: no problem
* Nero ShowTime: no problem
* Songbird 1.8.0: no problem, able to show and edit embedded pictures

'''Tested hardware players'''
* Logitech Squeezebox: Supported as of January 2009 (server version 7.3.3)
* Sandisk Sansa Fuze (Firmware 01.01.22): Hangs up when trying to playback the demo file - had to reset the player
** Note: The "Fuze" can play ogg vorbis files which have embedded pictures from "Easytag"
* Cowon iAudio U3 (Firmware 1.29, 4 GB): works
* Cowon D2: no problem (latest Firmware: 2.59, 8GB Version)
* iRiver E100: no problem (latest Firmware: 1.16 G_U, 8GB Version)
* Samsung YP-R1: no problem (latest Firmware: 3.07, 16GB Version)

'''Tested tag editors'''
* Easytag 2.1.6: can open the file to edit the normal tag fields
* MP3Tag 2.42e: can open the file to edit the normal tag fields
* MP3Tag 2.47b: is able to show and edit embedded pictures

'''Tested other software'''
* Total Recorder: capable to work with artwork according to the specification.

==== Unofficial COVERART field (deprecated) ====
There also exists an unofficial, not well supported comment field named "COVERART". It includes a base64-encoded string of the binary picture data (usually a JPEG file, but this could be a different file format too). The disadvantages are that
* no additional information like a description about the cover art or its type (front cover, back cover etc.) is provided,
* the cover art can't be linked
* the base64 string is displayed within many tag editors as plain text because of their missing support for this "COVERART" field
* it may breaks the playback on hardware players because of a large VorbisComment header
The unofficial "COVERART" field is supported for example by such software as AudioShell (http://www.softpointer.com/AudioShell.htm) - read/write, and Total Recorder (http://www.totalrecorder.com/)- only read.

===== Conversion to METADATA_BLOCK_PICTURE =====
Old "COVERART" tags should be converted to the new METADATA_BLOCK_PICTURE tag (see above for its specification). This conversion is straightforward and is suggested to be done the following way:

* Decode the COVERART tag. A program MAY check the signature of the embedded picture in order to determine whether it is an allowed type. Lossless conversion from disallowed types to allowed types MAY be carried out.
* Fill out the FLAC block with the binary picture data. If the MIME type of the picture is unknown or can't be determined, the MIME type "image/" MAY be used instead. Supplying image dimensions, color depth etc. is optional (see specification above).
* In the absence of other information the picture type 'Other' should be used. Applications may want to allow users to select a default type or specify the type to use.
* Encode the new picture block, remove the COVERART tag from the comments and add the METADATA_BLOCK_PICTURE entry.
* If multiple tags are being converted the order of the METADATA_BLOCK_PICTURE tags should be the same as that of the COVERART tags they are replacing.

=== Date and time ===

The goal is to specify '''one''' standard format for describing date and/or time.

==== ISO proposal ====
The date format for any field describing a date must follow the ISO scheme: YYYY-MM-DD, shortened to just YYYY-MM or simply YYYY.

We have been recommending this usage with the DATE tag for some time. It is proposed that the spec be amended to include this information for machinability.

The time format for any field '''except''' track duration must be specified with leading T and ending with a time zone. Schemas with and without dates:
<pre>
YYYY-MM-DDTHH:MM:SS+TS
</pre>
<pre>
THH:MM+TZ
</pre>

=== ENCODER ===

The goal is to attribute encoder software. This value can be used in the future to determine which files can be improved by being re encoded with a newer version.

:'''Comment''': What is lacking from the vendor string present in the spec from the start? All libvorbis and encoder tunings I'm aware of have recorded the encoder version here.

Rationale for not using the vendor string:
* The vendor string is usually used to store the name and version of the underlying codec library
* The idea of ENCODER is to store the name of the user-visible application, for example <tt>ffmpeg2theora</tt>.
* It can be useful for debugging to store the name and version of the calling application.
* The libvorbis API does not let applications override the vendor string.

==== Proposal: Inclusion of URL in ENCODER value ====
The encoder field name must be a unique URL providing both encoder software name and version. If no unique URL address is available were both name and version is available; then the version number can be specified by separating with a space character. For example:

<nowiki>ENCODER=http://flac.sourceforge.net/ 1.2.1</nowiki>

* Note that ffmpeg2theora uses ENCODER, but does not include a url. ''Added by Rillian on September 17, 2007''

==== Proposal: ENCODED_BY ====

I've also seen ENCODED_BY. ''Added by Rillian on September 17, 2007''
: ENCODED_BY is usually the person who did the encoding. This should not be part of the recommendation due to legal problems around deliberate and accidental distribution to third parties. Basically the name of the encoder should not be included to protect encoders from their own egos and possible legal prosecution. ''Added by Aleksandersen on September 20, 2007''

=== Improving license data ===

The goal is to provide a method for proclaiming license and copyright information (basically clarifying ‘distribution rights (if any) and ownership’).

The [http://xiph.org/vorbis/doc/v-comment.html specification document] describes LICENSE and COPYRIGHT fields. But is not clear enough about whether these should be machine-readable.

We should consider working together with Creative Commons to have complementary and interlinked information on the Creative Commons and Xiph wikis. Refer to the [http://wiki.creativecommons.org/Ogg Ogg page] in the Creative Commons wiki.

==== New RIGHTS field name proposal ====
One proposal is to replace the COPYRIGHT and LICENSE field names with RIGHTS. RIGHTS must be a human-readable copyright statement. Basic example:

<nowiki>RIGHTS=Copyright © Recording Company Inc. All distribution rights reserved.</nowiki>

But this is not machine-readable. Adding two complementary field names should do the trick: RIGHTS-DATE, describing the date of copyright; and RIGHTS-URI, providing a method for linking to a license. Software agents can assume that multiple songs uses the sameURIs, such as in the case for Creative Commons. Full example:

<nowiki>RIGHTS=Copyright © 2019 Recording Company Inc. All distribution rights reserved.</nowiki> 
<nowiki>RIGHTS-DATE=2019-04</nowiki> 
<nowiki>RIGHTS-URI=http://somewhere.com/license.xhtml</nowiki>

Software such as for multimedia management and playback are encouraged to display the RIGHTS statement as a linked phrase using RIGHTS-URI.

RIGHTS-DATE does not need to be displayed as it is required in the human readable version by international copyright agreements. RIGHTS-DATE can be used to determine when a copyrighted work falls under the public domain and related matters. (''The Beatles''' copyright on their original studio recordings (not the remixes) are soon expiering. So mechanisms such as the RIGHTS-DATE are indeed required in music management and filesharing software!)

To remain machine-readable it would be required to have at most one instance of each RIGHTS field name. All fields would of course remain optional.

The ''Dublin Core Metadata Initiative'' recommends the use of ‘rights’ to describe license and copyright matters. The web feed format Atom 1.0 has implemented a rights element in their specification.

:'''Comment''': The triplet RIGHTS, RIGHTS-DATE, RIGHTS-URI is an example of structured metadata. VorbisComments are inherently unstructured, and this should be respected. Structured metadata belongs in a different stream, such as XML (using [[Metadata#XMLEmbedding|XMLEmbedding]]).

==== Improving existing fields proposal ====
Similar to the DATE tag above, we have generally recommended that a URL uniquely identifying the license be included in the LICENSE field to allow machine identification of the license. This is in agreement with the proposal in the Creative Commons wiki. Since the COPYRIGHT field is a human-readable statement of the copyright, like the proposed RIGHTS tag above, some people include a license url there. Therefore if a url can't be found in a LICENSE tag if any, applications should use one from the COPYRIGHT tag, if any. Contact information for verification, attribution, relicensing, etc. can be obtained from the COPYRIGHT field, but Creative Commons also recommend a separate CONTACT tag for this information. This is reasonable, so we propose it be included.

=== Geo Location fields ===

The existing LOCATION field is meant to carry a human readable location for the recording/creation of the media file.

Having geographical coordinates according to [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84] can be useful as well, especially in a form that can be machine parsed. The agreed format is similar to this [http://en.wikipedia.org/wiki/Geo_(microformat) geo microformat]:

GEO_LOCATION= ''latitude'' ; ''longitude'' [; ''elevation'' ]

where each value is a fixed point decimal number formatted in the C locale with a period (.) for the radix. Values are separated with a ';' and white space is not significant. The elevation is optional.

''latitude'' is the geo latitude location of where the media has been recorded or produced in decimal degrees according to WGS84 (zero at the equator, negative values for southern latitudes) (C double).

''longitude'' is the geo longitude location of where the media has been recorded or produced in decimal degrees according to WGS84 (zero at the prime meridian in Greenwich/UK, negative values for western longitudes). (C double).

''elevation'' is the geo elevation of where the media has been recorded or produced in meters according to WGS84 (zero is average sea level) (C double).

=== Replay Gain ===

The REPLAYGAIN_* fields implement the Replay Gain proposal for storing a track relative volume adjustment, which can be used to "fix" quiet or loud sounding Vorbis or FLAC streams. The set of tags is intended to be machine parsed, and has the following form:
<pre>
REPLAYGAIN_TRACK_GAIN=-7.03 dB
REPLAYGAIN_TRACK_PEAK=1.21822226
REPLAYGAIN_ALBUM_GAIN=-6.37 dB
REPLAYGAIN_ALBUM_PEAK=1.21822226
</pre>

See http://www.replaygain.org/ for detailed information about Replay Gain and how the different values are calculated.

== Implementations ==

* [http://sbooth.org/importers/ OggImporter] – imports Ogg Vorbis and Ogg FLAC files to Spotlight.
* vorbiscomment – a commandline tool, part of [[VorbisTools]].
* [http://www.xiph.org/oggz/ oggz-comment] – a commandline tool, part of [[Oggz]] tool. It can add comments to multitrack and video files.

Field names

2011-01-15T16:04:12Z

Martin.leese: /* Analysis */ Typo

This page describes a proposed update to the minimal list of 15 standard field names in the [http://xiph.org/vorbis/doc/v-comment.html Vorbis I specification]. Please keep discussion confined to [[Talk:Field names|the Discussion page]] (or, better, the [http://lists.xiph.org/mailman/listinfo/vorbis-dev <vorbis-dev>] mailing list).

After the proposal has been discussed, and accepted or rejected, this page should be deleted.

== Analysis ==

To determine what field names are being used in the wild, the following resources were analysed:

* [http://age.hobba.nl/audio/mirroredpages/ogg-tagging.html Reactor Core proposal]
* [http://gophernet.org/articles/vorbiscomment/ Carnival of Technology proposal]
* Proposals on the XiphWiki [[VorbisComment]] page
* [http://sbooth.org/importers/ OggImporter to Spotlight]
* [http://easytag.sourceforge.net/ EasyTAG] tagging program (routine "ogg_tag.c" in the source code)
* [http://www.mp3tag.de/en/ Mp3tag] tagging program ([http://forums.mp3tag.de/index.php?showtopic=9730 post in the Mp3tag Forum])

The analysis is presented as an [http://lists.xiph.org/pipermail/vorbis-dev/attachments/20090716/e2db9203/attachment-0001.xls Excel spreadsheet] (note that it contains two sheets, the first of which is the more interesting).

== Proposal ==

The following modest list of additions to the minimal list in the specification is proposed:

# <code>COMPOSER</code>
# <code>TRACKTOTAL</code> – complements the existing <code>TRACKNUMBER</code>
# <code>DISCNUMBER</code> – used if part of a multi-disc album
# <code>DISCTOTAL</code> – total number of discs in a multi-disc album
# <code>ENCODED-BY</code> – see [[VorbisComment]] page
# <code>ENCODER</code> – see [[VorbisComment]] page
# <code>METADATA_BLOCK_PICTURE</code> – see [[VorbisComment]] page
# <code>SOURCEMEDIA</code> – recommended because two different field names have been proposed
# <code>PRODUCTNUMBER</code> – recommended because two different field names have been proposed

The field names <code>SOURCEMEDIA</code> and <code>PRODUCTNUMBER</code> could be dropped if Xiph does '''not''' wish to prescribe field names. (The alternatives which have also been proposed to store the same information are <code>SOURCE MEDIUM</code> and <code>EAN/UPN</code>, respectively.)

The field name <code>REMIXER</code> has '''not''' been included as its use is covered by the existing <code>VERSION</code>.

The triple <code>RIGHTS</code>, <code>RIGHTS-DATE</code>, <code>RIGHTS-URI</code>, proposed on the [[VorbisComment]] page, has '''not''' been included because this is structured metadata. VorbisComments are inherently unstructured and this should be respected.

Field names

2011-01-10T19:28:51Z

Martin.leese: /* Analysis */ Clarity

This page describes a proposed update to the minimal list of 15 standard field names in the [http://xiph.org/vorbis/doc/v-comment.html Vorbis I specification]. Please keep discussion confined to [[Talk:Field names|the Discussion page]] (or, better, the [http://lists.xiph.org/mailman/listinfo/vorbis-dev <vorbis-dev>] mailing list).

After the proposal has been discussed, and accepted or rejected, this page should be deleted.

== Analysis ==

To determine what field names are being used in the wild, the following resources were analysed:

* [http://age.hobba.nl/audio/mirroredpages/ogg-tagging.html Reactor Core proposal]
* [http://gophernet.org/articles/vorbiscomment/ Carnival of Technology proposal]
* Proposals on the XiphWiki [[VorbisComment]] page
* [http://sbooth.org/importers/ OggImporter to Spotlight]
* [http://easytag.sourceforge.net/ EasyTAG] tagging program (routine "ogg_tag.c" in the source code)
* [http://www.mp3tag.de/en/ Mp3tag] tagging program ([http://forums.mp3tag.de/index.php?showtopic=9730 post in the Mp3tag Forum])

The analysis is presented as an [http://lists.xiph.org/pipermail/vorbis-dev/attachments/20090716/e2db9203/attachment-0001.xls Excel spreadsheet] (note that it contains two sheets, the first of which is more interesting).

== Proposal ==

The following modest list of additions to the minimal list in the specification is proposed:

# <code>COMPOSER</code>
# <code>TRACKTOTAL</code> – complements the existing <code>TRACKNUMBER</code>
# <code>DISCNUMBER</code> – used if part of a multi-disc album
# <code>DISCTOTAL</code> – total number of discs in a multi-disc album
# <code>ENCODED-BY</code> – see [[VorbisComment]] page
# <code>ENCODER</code> – see [[VorbisComment]] page
# <code>METADATA_BLOCK_PICTURE</code> – see [[VorbisComment]] page
# <code>SOURCEMEDIA</code> – recommended because two different field names have been proposed
# <code>PRODUCTNUMBER</code> – recommended because two different field names have been proposed

The field names <code>SOURCEMEDIA</code> and <code>PRODUCTNUMBER</code> could be dropped if Xiph does '''not''' wish to prescribe field names. (The alternatives which have also been proposed to store the same information are <code>SOURCE MEDIUM</code> and <code>EAN/UPN</code>, respectively.)

The field name <code>REMIXER</code> has '''not''' been included as its use is covered by the existing <code>VERSION</code>.

The triple <code>RIGHTS</code>, <code>RIGHTS-DATE</code>, <code>RIGHTS-URI</code>, proposed on the [[VorbisComment]] page, has '''not''' been included because this is structured metadata. VorbisComments are inherently unstructured and this should be respected.