Re: [MP3 ENCODER] Vorbis
On Tue, 8 Aug 2000, Ivo wrote: > Playing it in XMMS, though, hinted that my P133 is not fast enough to > play ogg, since CPU load was 100% and playback awful. > Does decoding really take so much CPU power on a P133 or should it be more > reasonable? Decoding really does take that much power on a pentium. The vorbis playback code is not optimised. Hopefully someone will optimise the playback. The hints I have seen on the vorbis mailing list suggest that vorbis playback is not inherently much more complex than mp3 playback and that large improvements are possible. Chris Wise -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Vorbis
Speaking of Vorbis, when (if) will Vorbis support (with no extra downloads & no extra hassle) be built into the downloadable source code? Cheers, David -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Vorbis
Apologizing for offtopicness beforehand, I'd like to ask something about Vorbis. I've compiled Vorbis support into LAME and the XMMS plugin from a nightly build. I've tried encoding an ogg file and it went file. Playing it in XMMS, though, hinted that my P133 is not fast enough to play ogg, since CPU load was 100% and playback awful. Does decoding really take so much CPU power on a P133 or should it be more reasonable? Ivo -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] vorbis comment header patch
Cool! I didn't even think to add vorbis support when I landed the id3v2
stuff this week. Nice idea, Ralph!
The "tag_spec" is supposed to be a private data structure so I don't
want us to be reading it directly for the long term, but this will
method work fine for now. :-)
I'll try the patch out tonight when I get home and see if I can land it
in the tree. Stay tuned.
On Thu, Jul 06, 2000 at 04:41:59PM -0700, Ralph Giles wrote:
> Here's a rough patch to make the --t* options work with the vorbis
> encoder. I just read the id3tag_spec structure directly, but the vorbis
> comment header is a lot more flexible than the id3 stuff, so I'd really
> want to write a general token-value interface to the metadata if I were
> "doing it right." Maybe some other time.
This is probably a stupid question, but are there docs online about the
comment header (he asks without even looking at the vorbis site first)?
> bugs:
>
> Doesn't support track number of genre. The second is easy to add; the
> first requires that the vorbis people settle on a standard form for it.
Let me see if I can contact them about their plans for this. If you
find out anything, let us all know. Maybe I can hack in the genre. :-)
> Ogg encoding doesn't actually work for me; it prints a lot of:
>
> *
> decoded bytes=0 16384
>
> And generates a 128 byte file. This happens without my patch as well.
>
> Oops, on further investigation those 128 bytes are an id3 tag, so we need
> an interlock of some sort. I'll take a look at this later.
Cool. Just send another patch.
> Cheers,
> -ralph
>
> --
> [EMAIL PROTECTED]
> Ahh, the joys of tracking cvs!
>
> Index: parse.c
> ===
> RCS file: /cvsroot/lame/lame/parse.c,v
> retrieving revision 1.68
> diff -u -r1.68 parse.c
> --- parse.c 2000/07/04 03:28:43 1.68
> +++ parse.c 2000/07/06 23:34:44
> @@ -180,6 +180,9 @@
>PRINTF1("characters), or the `--add-id3v2' or `--id3v2-only' options are
>used,\n");
>PRINTF1("or output is redirected to stdout.\n");
>PRINTF1("\n");
> + PRINTF1("The --t* options will work with the Ogg encoder, but the
>id3-specific\n");
> + PRINTF1("features will be ignored. Genre and tracknumber are currently
>ignored.\n");
> + PRINTF1("\n");
> #ifdef HAVEGTK
>PRINTF1("-g run graphical analysis on \n");
> #endif
> @@ -832,6 +835,3 @@
>}
>
> }
> -
> -
> -
> Index: vorbis_interface.c
> ===
> RCS file: /cvsroot/lame/lame/vorbis_interface.c,v
> retrieving revision 1.10
> diff -u -r1.10 vorbis_interface.c
> --- vorbis_interface.c2000/06/30 14:25:53 1.10
> +++ vorbis_interface.c2000/07/06 23:34:50
> @@ -93,7 +93,7 @@
> set up the Vorbis decoder */
>
>/* The next two packets in order are the comment and codebook headers.
> - They're likely large and may span multiple pages. Thus we reead
> + They're likely large and may span multiple pages. Thus we read
> and submit data until we get our two pacakets, watching that no
> pages are missing. If a page is missing, error out; losing a
> header page is the only place where missing data is fatal. */
> @@ -225,11 +225,6 @@
>break;
> }
>
> -
> -
> -
> -
> -
> result=ogg_sync_pageout(&oy,&og);
>
> if(result==0) {
> @@ -300,15 +295,6 @@
>
>
>
> -
> -
> -
> -
> -
> -
> -
> -
> -
> ogg_stream_state os2; /* take physical pages, weld into a logical
> stream of packets */
> ogg_page og2; /* one Ogg bitstream page. Vorbis packets are inside */
> @@ -320,13 +306,13 @@
> vorbis_dsp_state vd2; /* central working state for the packet->PCM decoder */
> vorbis_block vb2; /* local working space for packet->PCM decode */
>
> -
>
> +#define vorbis_comment_size 256
>
> int lame_encode_ogg_init(lame_global_flags *gfp)
> {
>lame_internal_flags *gfc=gfp->internal_flags;
> -
> + char comment[vorbis_comment_size];
>
>/** Encode setup /
>
> @@ -337,10 +323,43 @@
>vi2.rate = gfp->out_samplerate;
>
>
> - /* add a comment */
> + /* fill out the comments header */
>vorbis_comment_init(&vc2);
>vorbis_comment_add(&vc2,"Track encoded using L.A.M.E. libvorbis interface.");
> -
> +
> + /* these fields are marked "private data members" in the header, so
> + 'twould be better to add id3tag_get_*() functions instead. However,
> + the vorbis comment fields are much more flexible than the id3 stuff
> + so I'll just do this in anticipation of (another) metatag rewrite */
> +
> + if(gfp->tag_spec.title) {
> + snprintf(comment,vorbis_comment_size,
> + "TITLE=%s",gfp->tag_spec.title);
> + vorbis_comment_add(&vc2,comment);
> + }
> + if(gfp->tag_spec.artist) {
> + snprintf(comment,vorbis_comment_size,
> + "ARTIST=%s",gf
[MP3 ENCODER] vorbis comment header patch
Here's a rough patch to make the --t* options work with the vorbis
encoder. I just read the id3tag_spec structure directly, but the vorbis
comment header is a lot more flexible than the id3 stuff, so I'd really
want to write a general token-value interface to the metadata if I were
"doing it right." Maybe some other time.
bugs:
Doesn't support track number of genre. The second is easy to add; the
first requires that the vorbis people settle on a standard form for it.
Ogg encoding doesn't actually work for me; it prints a lot of:
*
decoded bytes=0 16384
And generates a 128 byte file. This happens without my patch as well.
Oops, on further investigation those 128 bytes are an id3 tag, so we need
an interlock of some sort. I'll take a look at this later.
Cheers,
-ralph
--
[EMAIL PROTECTED]
Ahh, the joys of tracking cvs!
Index: parse.c
===
RCS file: /cvsroot/lame/lame/parse.c,v
retrieving revision 1.68
diff -u -r1.68 parse.c
--- parse.c 2000/07/04 03:28:43 1.68
+++ parse.c 2000/07/06 23:34:44
@@ -180,6 +180,9 @@
PRINTF1("characters), or the `--add-id3v2' or `--id3v2-only' options are
used,\n");
PRINTF1("or output is redirected to stdout.\n");
PRINTF1("\n");
+ PRINTF1("The --t* options will work with the Ogg encoder, but the
+id3-specific\n");
+ PRINTF1("features will be ignored. Genre and tracknumber are currently
+ignored.\n");
+ PRINTF1("\n");
#ifdef HAVEGTK
PRINTF1("-g run graphical analysis on \n");
#endif
@@ -832,6 +835,3 @@
}
}
-
-
-
Index: vorbis_interface.c
===
RCS file: /cvsroot/lame/lame/vorbis_interface.c,v
retrieving revision 1.10
diff -u -r1.10 vorbis_interface.c
--- vorbis_interface.c 2000/06/30 14:25:53 1.10
+++ vorbis_interface.c 2000/07/06 23:34:50
@@ -93,7 +93,7 @@
set up the Vorbis decoder */
/* The next two packets in order are the comment and codebook headers.
- They're likely large and may span multiple pages. Thus we reead
+ They're likely large and may span multiple pages. Thus we read
and submit data until we get our two pacakets, watching that no
pages are missing. If a page is missing, error out; losing a
header page is the only place where missing data is fatal. */
@@ -225,11 +225,6 @@
break;
}
-
-
-
-
-
result=ogg_sync_pageout(&oy,&og);
if(result==0) {
@@ -300,15 +295,6 @@
-
-
-
-
-
-
-
-
-
ogg_stream_state os2; /* take physical pages, weld into a logical
stream of packets */
ogg_page og2; /* one Ogg bitstream page. Vorbis packets are inside */
@@ -320,13 +306,13 @@
vorbis_dsp_state vd2; /* central working state for the packet->PCM decoder */
vorbis_block vb2; /* local working space for packet->PCM decode */
-
+#define vorbis_comment_size 256
int lame_encode_ogg_init(lame_global_flags *gfp)
{
lame_internal_flags *gfc=gfp->internal_flags;
-
+ char comment[vorbis_comment_size];
/** Encode setup /
@@ -337,10 +323,43 @@
vi2.rate = gfp->out_samplerate;
- /* add a comment */
+ /* fill out the comments header */
vorbis_comment_init(&vc2);
vorbis_comment_add(&vc2,"Track encoded using L.A.M.E. libvorbis interface.");
-
+
+ /* these fields are marked "private data members" in the header, so
+ 'twould be better to add id3tag_get_*() functions instead. However,
+ the vorbis comment fields are much more flexible than the id3 stuff
+ so I'll just do this in anticipation of (another) metatag rewrite */
+
+ if(gfp->tag_spec.title) {
+ snprintf(comment,vorbis_comment_size,
+ "TITLE=%s",gfp->tag_spec.title);
+ vorbis_comment_add(&vc2,comment);
+ }
+ if(gfp->tag_spec.artist) {
+ snprintf(comment,vorbis_comment_size,
+ "ARTIST=%s",gfp->tag_spec.artist);
+ vorbis_comment_add(&vc2,comment);
+ }
+ if(gfp->tag_spec.album) {
+ snprintf(comment,vorbis_comment_size,
+ "ALBUM=%s",gfp->tag_spec.album);
+ vorbis_comment_add(&vc2,comment);
+ }
+ /* pretend these are equivalent */
+ if(gfp->tag_spec.comment) {
+ snprintf(comment,vorbis_comment_size,
+ "DESCRIPTION=%s",gfp->tag_spec.comment);
+ vorbis_comment_add(&vc2,comment);
+ }
+ if(gfp->tag_spec.year) {
+ snprintf(comment,vorbis_comment_size,
+ "DATE=%d",gfp->tag_spec.year);
+ vorbis_comment_add(&vc2,comment);
+ }
+ /* FIXME: we drop the track number and genre for now */
+
/* set up the analysis state and auxiliary encoding storage */
vorbis_analysis_init(&vd2,&vi2);
vorbis_block_init(&vd2,&vb2);
@@ -375,6 +394,7 @@
return 0;
}
+#undef vorbis_comment_
Re: [MP3 ENCODER] vorbis -> mp3
Mark Taylor wrote: > > > > > > > can somebody help me? i want to test vorbis->mp3 encoding of my > > compile, where i can get vorbis files (file)? > > > > > > > > > > Best regards, > > Dmitrymail to: [EMAIL PROTECTED] > > > > > > ftp.sulaco.org/pub > > I just put a few .ogg files there. These are just examples that I used to > debug the .ogg file reading capabilities in LAME. The were made with > the vorbis decoder_example, and probably not the latest version of > libvorbis. > > I've also started to add a "--ogg" option so that LAME can produce > .ogg files, but it is not working yet. > > Mark So the there will be ogg ( vorbis ? ) support in lame ? Input, output or both ? Isn't this bloat ? After all lame is supposed to be an MP3 encoder ... David Balazic -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] vorbis -> mp3
> can somebody help me? i want to test vorbis->mp3 encoding of my > compile, where i can get vorbis files (file)? > > > Best regards, > Dmitrymail to: [EMAIL PROTECTED] > cut from vorbis-dev mailing list: Michael Smith wrote: MS> Finally, I've put up copies of the windows encoder, and the winamp plugin at MS> http://www.labyrinth.net.au/~msmith/in_vorbis.dll MS> http://www.labyrinth.net.au/~msmith/example_encoder.exe MS> for anyone who wants to try this stuff out but doesn't have appropriate MS> tools, like a compiler. MS> MS> Michael -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] vorbis -> mp3
> > > can somebody help me? i want to test vorbis->mp3 encoding of my > compile, where i can get vorbis files (file)? > > > > > Best regards, > Dmitrymail to: [EMAIL PROTECTED] > > ftp.sulaco.org/pub I just put a few .ogg files there. These are just examples that I used to debug the .ogg file reading capabilities in LAME. The were made with the vorbis decoder_example, and probably not the latest version of libvorbis. I've also started to add a "--ogg" option so that LAME can produce .ogg files, but it is not working yet. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] vorbis -> mp3
can somebody help me? i want to test vorbis->mp3 encoding of my compile, where i can get vorbis files (file)? Best regards, Dmitrymail to: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
