[vorbis-dev] my vorbis comments

[sbj at mit.edu]

Ok I just finished writing a Vorbis encoder/decoder, and here are some
of my comments (I'm sure some of these are well known, but here they
are anyway - sorry this is long):

1. vorbis_info:
  a. Accessing the pre-computed info structs through pointers to
     static data is messy IMO.  I should be able to vorbis_info_init
     (or similar) an info struct to be exactly the same as info_A, for
     instance.  That way, I could vorbis_clear and free it at the end
     just like I do for vorbis_info's which come from a vorbis file
  b. A function which compares two vorbis_info structs, to see if they
     are equivalent (i.e. would produce the same output for a given
     input stream) This would be useful say if I am copying an input
     vorbis file (whose info is not info_[A-E]) to an output vorbis
     file with a specific info, I could determine then whether it is
     necessary to actually re-encode, or whether I could just copy
     packets.
  c. A way to cleanly write a file using the same info struct I pulled
     from an input vorbis file.  vorbiscomment.c, of course, has this
     same problem, and so I had to borrow the hack from there.
  d. People say the info_[A-E] has approximate bitrate X, but those
     structs don't have the bitrate_* fields set, what's up with that?
  e. The other stuff I'm _sure_ you folks are already working on, for
     example:
    i. A more general way to choose an info struct
2. vorbisfile:
  Write capability.
3. ogg_page:
  A way to compute page length.  In order to compute the page length,
  I've been adding header_len and body_len - which is currently
  correct - but it's not part of the spec as far as I can tell.
  ogg_sync_pageseek would tell me the page length, but if I should use
  that, then who needs ogg_sync_pageout?
4. analysis/synthesis:
  a. I wouldn't mind if vorbis didn't use separated channel buffers,
     but since I don't understand the compression details, they might
     be really important.
  b. I also wouldn't mind if there were vorbis_read_header
     /_write_header functions which handled the first 3 packets for
     me.
5. chained streams:
  a. The fact that vorbis allows different sampling-rate sounds to be
     chained together makes my head want to explode.

Finally, this last note could be a bug in my code, I have not finished
looking into it.  But I thought I'd mention it.  Feel free to ignore
from here on.

  When I read the first three packets (the headers) of a vorbis file,
  I expect that when I am finished reading the last packet, the offset
  into the stream (as computed by adding the page sizes together)
  should be the offset of the first sound page.  I don't know if
  that's spec, but it's what vorbisfile does, so I took it as gospel.
  However, when _my_ program does it, I end up needing 1 more page
  than I should for that last packet.  That is, I have to _pagein the
  first sound page before I can _packetout the last header packet.

  The only differences I have seen so far between vorbisfile and my
  program which are relevant to this problem is that vorbisfile uses
  ogg_sync_pageseek to get those pages, while I am using
  ogg_sync_pageout.

                               jamie

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.