Hi !
<p>I previously posted a mail in the vorbis-dev mailing list because
I'm
trying to implement a vorbis decoder in java from scratch in my
sparetime and have some questions about the bitstream spec.
As I did not get any replies, I got kinda dissapointed and
demotivated - But now.... I'm trying to take my chances here.
:-)
I'm NOT a newbie to source coding (I successfully coded an MPEG1
Layer II decoder from scratch by the ISO spec draft).
Therefore, the following questions might be quite reasonable.
(...and might be useful for improving the spec?)
<p>Decode setup - Identification header
------------------------------------
- AFAIK Vorbis uses MDCT transforms which will result in 'spectral-
vectors' of the length 1024 (for long blocks) and 128 (for short
blocks) at 44kHz, so I expected the two 4-bit exponents in the
identification header to be 7 and 10, but I found 8 and 11 in
my Oggs. So the "blocksize" values correspond to the nominal
window-length instead of the length of the 'spectral-vector' ??
I find it a bit confusing and inconsistent. (Compare to 'vorbis-
spec-intro.html': 64...8192 samples/frame)
I suggest adding a note for clarification.
<p>Floor 0 format - header decode
------------------------------
- Step 7: how could any of those values be less than zero
if i read them as unsigned integers ?
<p>Floor 0 format - curve computation
----------------------------------
- What is [n] in context of the 'map_i = minimum { ...'-
iteration ? I tend to think [n] is still the length
of the final floor vector to be computed and the [map]
vector is used to map an element of the final-floor
vector to a bark-scale frequency, is this correct ?
- The formulas for p and q make use of omega, but there's
nothing in the spec about omega... How is omega related
to [i] or to ([map] element [i]) ?
I can only assume.... omega = map[i]/bark_map_size ?
<p>thanks in advance,
Sebastian
--- >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-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
Sebastian Gesemann wrote:> - AFAIK Vorbis uses MDCT transforms which will result in 'spectral- > vectors' of the length 1024 (for long blocks) and 128 (for short > blocks) at 44kHz, so I expected the two 4-bit exponents in the > identification header to be 7 and 10, but I found 8 and 11 in > my Oggs. So the "blocksize" values correspond to the nominal > window-length instead of the length of the 'spectral-vector' ??Assuming windows are always exactly 2:1 overlapped, yes. This is an oversight, but just divide by 2 and you'll be fine.> I find it a bit confusing and inconsistent. (Compare to 'vorbis- > spec-intro.html': 64...8192 samples/frame) > I suggest adding a note for clarification.Why don't you write a patch for the doc? :-)> Floor 0 format - header decode > ------------------------------ > - Step 7: how could any of those values be less than zero > if i read them as unsigned integers ?If you don't quote the relevant part of the doc, I can't answer this, sorry. Try again?> Floor 0 format - curve computation > ---------------------------------- > - What is [n] in context of the 'map_i = minimum { ...'-Same here... <p>Segher --- >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-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Hi ! once again.... WITH quotes from the spec ;) Floor 0 format - header decode ------------------------------ - Step 7: how could any of those values be less than zero if i read them as unsigned integers ? the spec says: | 1) [floor0_order] = read an unsigned integer of 8 bits | 2) [floor0_rate] = read an unsigned integer of 16 bits | 3) [floor0_bark_map_size] = read an unsigned integer of 16 bits | 4) [floor0_amplitude_bits] = read an unsigned integer of six bits | 5) [floor0_amplitude_offset] = read an unsigned integer of eight | bits | 6) [floor0_number_of_books] = read an unsigned integer of four | bits and add 1 | 7) if any of [floor0_order], [floor0_rate], | [floor0_bark_map_size], [floor0_amplitude_bits], | [floor0_amplitude_offset] or [floor0_number_of_books] are | less than zero, the stream is not decodable | 8) array [floor0_book_list] = read a list of [floor0_number_of_books] | unsigned integers of eight bits each; If one implements it that way, step 7 will never return a 'stream_undecodable_exception' because of the always positive values. Just want to know how I should do this kind of consistency check.... how it is supposed to be. <p>Floor 0 format - curve computation ---------------------------------- I'm not going to quote all the stuff here, but have a look at http://www.xiph.org/ogg/vorbis/doc/vorbis-spec-floor0.html paragraph: "curve computation" (right in the middle) | 1) [i] = 0 | : | : | 3) calculate [p] and [q] according to | http://www.xiph.org/ogg/vorbis/doc/oddlsp.png | : | : | 4) calculate [p] and [q] according to | http://www.xiph.org/ogg/vorbis/doc/evenlsp.png | : | :> - The formulas for p and q make use of omega, but there's > nothing in the spec about omega... How is omega related > to [i] or to ([map] element [i]) ?perhaps omega = pi * map[i] / bark_map_size ? <p>PS: I can't write a patch for the doc if i don't know how it's supposed to be. <p>bye, Sebastian --- >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-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.