[vorbis-dev] Replay to the 'oggenc ideas/source and request' replays

[Attila Padar]

Dear Developer Team (Monty/Michael Smith/and others),

It seems you get angry for me, but I don't understand why.
I don't want to dispute with you, but maybe I forgot to say some things...
Here they are:
1. My program (clone) is not a finalized, and NOT A RELEASED (public)
   program.  This is just a test, I wrote it to myself, 
   to the (sound quality) comparsion of  MP3 and OGG.

2. Because of this don't worry about the copyright information, 
   I acknowledge your merit in this development, and I don't want 
   to public this oggenc as my own program.

3. Sometimes your solutions are too complicate for me (long or passes 
   my comprehension), because of this I write my own code to the same 
   solution/problem... And:
   a, it seems (maybe I mistake)  your wav routines do not handle the 
      wav-data-len value (readed from the 'data' chunk)...
      read until the end of file is not correct, because sometimes the 
      wav file has got some extra infos/datas behind the audio data
   b, you wrote two separated (mono and stereo) routines, my routine is 
      a general solution to every number of channels... (Monty said that 
      it's already implemented...) (but that's right, I've also "never 
      seen a wav file with more than 2 channels in it")
   c, I just thought that I can give you some new ideas...

4. average-bitrate: maybe you are right, just I thought that if we know
   the average bitrate and the size of file, we can compute easily the
   length of song (timesec=filesize*8/bitrate)... but that's right,
   the granulepos from the last granule always give a correct value,
   and the average bitrate sometimes may be incorrect...
   (of course, if a program 'edit' an ogg file, it should update the
    bitrate in the header)

5. 64 bits vs. 32: I don't know, because of this I would like to test it.
   But I don't think so "it makes zero difference".
   I know, with 64 bits the program is slower with 20-25%, but if I can
   get a little bit better quality on this way, I don't care with it.
   (encoding runs 5 or 6 minutes? it's small difference)

6.
> You've put the entirety of libvorbis into a single file, along with the 
> encoder. Why?
   My request was that: "If somebody has a little time, please make an 
   executable from this source"
   I thought so, that 'somebody' can easily compile it, if all sources 
   are in one C file...
   In my 'original' encoder, the functions are in the original, separated 
   C files (except the include files)...

7. I know, I have to find the 'bug' (compiler bug) in the encoder, but
   it's a 3-4 weeks job for me (I don't know the encoder functions yet)...
   The compiling request is just a fast help for me...

And I have some new questions:
8. comment field specification: I understand it... but what's then,
   if I want to modify the comments (artist/title or other)?
   If the new comment field is longer than the old one, 
   I have to duplicate the whole file... or not? Idea? 
   (How can I insert 100-150 (new) bytes into a file?)
   I've got an idea... but you will not like it. :)
   What do you think about a normal ID3TAG support (like at MP3s)?
   It's a fixed structure (128 bytes) at the end of file.
   We can add, modify and remove easily... 
   Without the encoder/decoder routines too...

9. ogg stream: The ogg is stream at all? It has got a header...
   I can't imagine, how will we use at an internet radio (just example).
   We have to transmit the header many times (in every 5. or 10. seconds).
   Idea?

orry that I bother you again...
sincerely
Attila Padar

--- >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.