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

[Michael Smith]

At 01:05 PM 12/11/00 +0100, you wrote:
>Dear Developer Team (Monty/Michael Smith/and others),
>
>It seems you get angry for me, but I don't understand why.

We're not getting angry with you. However, some criticism needed to be
given. We gave it - if we were too blunt, I'm sorry. We didn't mean to be
rude.

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

Handling these two points as one: you may not have meant anything bad.
However, you did publically make this source available with some of the
copyright notices removed. That IS releasing it, regardless of whether it's
a widespread final release or not. That's illegal. I suggest you remove the
zip files until you've corrected this. I (and others, I assume) understand
that you didn't mean this badly, but it was an unfortunate error on your part.

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

That was a mistake in an old version of oggenc, but it was corrected some
time ago (well before beta3). It reads until the data length value or end
of file, whichever comes first (truncated wav files are very common, so you
can't trust the data length value in general)
As it is, your code gets this right, but is extremely unportable (you don't
account for differing int sizes, for struct padding, and so on). You also
use some platform-specific functions elsewhere in your code.

>   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")

Yes, and I agreed that oggenc should do that. The reason it doesn't at the
moment is that it initially only supported stereo - and it was easier to
just add an extra function to deal with mono than to do it generically,
since >2 channel wav files don't exist to my knowledge. I'll probably
replace the code there with generic n-channel stuff at some point.

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

It's pretty straightforward to correctly calculate the bitrate. Since
you'll always need code to do that (since you CANNOT rely on that bitrate
value being correct), there's little point in having special-case code like
this.

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

Ok, so you want to try it. We're not going to stop you, but we're not
particularly interested in it either. The quality will NOT be changed, the
speed will be significantly decreased.

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

No, this actually makes it MUCH more difficult to compile it, using
real-world compilers. It's a bad idea for many other reasons, too.

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

Since this isn't portable code any more, and it's a huge file, it's more
effort than it's worth to compile it for you.

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

You just need to re-build a single page (or perhaps two), unless the
comment header grows beyond 64kB. It's not that hard. The whole point of
the vorbis comment header was to avoid disgusting hacks like ID3, which are
far too limited, and are generally a pain to use.

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

Yes, it's a stream - the header is constructed once, and sent at the start
(unlike, say, a wav header - that contains information which is often not
available until you've finished, so it's not truly streamable). For
internet radio purposes, you just send the headers to clients as they
connect - there's no need to re-transmit it continually.

Michael

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