[9fans] APEified OGG/Vorbis player

[9fans] APEified OGG/Vorbis player

[Sascha Retzki]

Hi fans,

I have written an OGG/Vorbis player and put it online at:

/n/sources/contrib/sascharetzki/src/ls-dj.tgz

Get your soundblaster 16, dust it, and bind #A! Let's get this party started.


You may find it dirty inside, yes it is.

Re: [9fans] APEified OGG/Vorbis player

[Russ Cox]

Where does one find the vorbis library port?

On 9/15/06, Sascha Retzki <sretzki@gmx.de> wrote:
>
> Hi fans,
>
> I have written an OGG/Vorbis player and put it online at:
>
> /n/sources/contrib/sascharetzki/src/ls-dj.tgz
>
> Get your soundblaster 16, dust it, and bind #A! Let's get this party started.
>
>
> You may find it dirty inside, yes it is.
>
>

Re: [9fans] APEified OGG/Vorbis player

[Sascha Retzki]

> Where does one find the vorbis library port?

There are two I am aware of, cnielsen got the libraries at sources, and anyrhine got them in the Internets. ( http://www.cs.helsinki.fi/u/anyrhine/p9/ ). I used anyrhines for development and testing, and put some notes about the installation process of the libraries in the file '9OGG-Vorbis' in ls-dj.tgz.

> 
> On 9/15/06, Sascha Retzki <sretzki@gmx.de> wrote:
>>
>> Hi fans,
>>
>> I have written an OGG/Vorbis player and put it online at:
>>
>> /n/sources/contrib/sascharetzki/src/ls-dj.tgz
>>
>> Get your soundblaster 16, dust it, and bind #A! Let's get this party started.
>>
>>
>> You may find it dirty inside, yes it is.
>>
>>

Re: [9fans] APEified OGG/Vorbis player

[erik quanstrom]

you may get by adding this line:

/n/sources/plan9//sys/src/cmd/file.c:8011,808 - file.c:800,801 
	".\\\"",		"troff input",		3,	"text/plain",
	".de",			"troff input",		3,	"text/plain",
	".if",			"troff input",		3,	"text/plain",
	".nr",			"troff input",		3,	"text/plain",
 	".tr",			"troff input",		3,	"text/plain",
+ 	"OggS",			"ogg",			4,	"application/ogg",
  	0,0,0,0
  };

Re: [9fans] APEified OGG/Vorbis player

[Sascha Retzki]

> you may get by adding this line:

Another problem is that OGG is just a container format. The file may not be a single vorbis stream, but several, or a video stream, etc. Container formats are pretty neat - at least that one tells you what is in the OGG. Your code will just tell the user that it is really an ogg, but not much more :(



> 
> /n/sources/plan9//sys/src/cmd/file.c:8011,808 - file.c:800,801 
> 	".\\\"",		"troff input",		3,	"text/plain",
> 	".de",			"troff input",		3,	"text/plain",
> 	".if",			"troff input",		3,	"text/plain",
> 	".nr",			"troff input",		3,	"text/plain",
>  	".tr",			"troff input",		3,	"text/plain",
> + 	"OggS",			"ogg",			4,	"application/ogg",
>   	0,0,0,0
>   };

Re: [9fans] APEified OGG/Vorbis player

[Skip Tavakkolian]

>> you may get by adding this line:
> 
> Another problem is that OGG is just a container format. The file may not be a single vorbis stream, but several, or a video stream, etc. Container formats are pretty neat - at least that one tells you what is in the OGG. Your code will just tell the user that it is really an ogg, but not much more :(

there are many (asf, quicktime, realmedia).  each has a mime type, but
the mime types do not identify the internal contents.  it is enough to
decide what handler to give it to. that's adequate for file.

Re: [9fans] APEified OGG/Vorbis player

[erik quanstrom]

sure you could add a new function to file to handle the 15 or so codecs
that ogg supports, but i'm not sure you gain anything.  do you expect to
have a lot of non-audio ogg that your player can't handle?

i disagree with skip.  i don't see the advantage to container formats.
they mostly encourage yet-another-(audio|video)-codex with some
neeto property that is inevitably less useful than standardization.

- erik

Re: [9fans] APEified OGG/Vorbis player

[Skip Tavakkolian]

> i disagree with skip.  i don't see the advantage to container formats.
> they mostly encourage yet-another-(audio|video)-codex with some
> neeto property that is inevitably less useful than standardization.

how did i encourage that? 
it's reasonable for 'file' to return something one can map to a
handler, that can further crack it open. containers may be ugly
but they're not the real problem - most if not all are described
somewhere. the main issues is proprietary codecs.

proprietary formats are marketing devices to protect turfs.

Re: [9fans] APEified OGG/Vorbis player

[Harri Haataja]

On Sat, Sep 16, 2006 at 03:13:12AM -0500, erik quanstrom wrote:
> sure you could add a new function to file to handle the 15 or so
> codecs that ogg supports, but i'm not sure you gain anything.  do you
> expect to have a lot of non-audio ogg that your player can't handle?
> 
> i disagree with skip.  i don't see the advantage to container formats.
> they mostly encourage yet-another-(audio|video)-codex with some
> neeto property that is inevitably less useful than standardization.

There's also .ogm[0] and .spx[1] that I believe are the same container
but with different internals. FLAC[2] is also seen in ogg wrappers as
well as in its own container[3].

Then there's also Matroska[4] that has .mkv / .mka split. I've only seen
that used as a "better .avi/.asf/.mov".

It's true that unless you're making some multimedia monster, those are
probably some headache. I personally believe that file extensions aren't
really useful for anything more than hints. Otoh, it really is annoying
if a (supposedly) "ogg" player can't play flac or speex codec tracks
just as well as it can do vorbis. Of course it all doesn't have to be
crammed into one if you can separate those bits and make up something
around that that will eat anything and give expected results whatever
the technical details are.


[0] http://en.wikipedia.org/wiki/Ogg_Media
[1] http://en.wikipedia.org/wiki/Speex
[2] http://en.wikipedia.org/wiki/FLAC
[3] http://flac.sourceforge.net/
[4] http://en.wikipedia.org/wiki/Matroska

-- 
Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live.
    -- John F. Woods

Re: [9fans] APEified OGG/Vorbis player

[Russ Cox]

I think you're overreacting.  Since one must use the
Ogg library to play the files anyway, it is entirely reasonable
to ask the Ogg library whether it is capable of playing
the file, rather than shelling out to some external
program that might or might not make the same
decisions.

The suggestion to use file(1) instead was predicated
on ov_open somehow cozying up to stdio and making
it break, an accusation that has turned out to be false.
In reality ov_open is perfectly well documented
(http://www.xiph.org/vorbis/doc/vorbisfile/ov_open.html)
and does exactly what is called for without any extra work.
Just use that.

Also, the MIME type should be application/x-ogg unless
ogg has  actually been registered with the MIME people.

Russ

Re: [9fans] APEified OGG/Vorbis player

[erik quanstrom]

the file package on my linux box returns application/ogg.

i suggested using file.  let me explain what i thought the idea
was.  file(1) is generally used to decide what to do with a file.
i thought that following that practice would be a good idea.
with a bit more effort than my original, file(1) could recognize
just ogg/vorbis files.

- erik

Re: [9fans] APEified OGG/Vorbis player

[erik quanstrom]

i don't think i said you encouraged anything.  if i did, i take it back.

your point is well taken, however i think this is a vicious cycle.
container formats encourage the development of yet more codecs of
all flavors.  lots of codecs encourage the development of containers.
so which one is "worse" becomes less important.

kind of a bummer.

- erik

On Sat Sep 16 03:48:32 CDT 2006, 9nut@9netics.com wrote:
> > i disagree with skip.  i don't see the advantage to container formats.
> > they mostly encourage yet-another-(audio|video)-codex with some
> > neeto property that is inevitably less useful than standardization.
> 
> how did i encourage that? 
> it's reasonable for 'file' to return something one can map to a
> handler, that can further crack it open. containers may be ugly
> but they're not the real problem - most if not all are described
> somewhere. the main issues is proprietary codecs.
> 
> proprietary formats are marketing devices to protect turfs.
>