[vorbis-dev] Replay to the 'oggenc ideas/source and request' replays
galileog at externet.hu
Mon Dec 11 04:05:40 PST 2000
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
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)
> 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).
orry that I bother you again...
--- >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.
More information about the Vorbis-dev