For the Vorbis file I'm using to develop my decoder, I've read the Ogg header at the start of the file, and now I'm reading the Vorbis identification header. Everything checks out fine until I get to the block size byte (offset 28 starting at the packet type field). The byte value here is 184, which is a bit pattern of: 1011 1000. The low order 4 bits are 8. Squaring it gives 64. This is valid according to the specs (as I understand them). The upper 4 bits are 11. Squaring it gives 121. This is not valid according the the specs: "Allowed final blocksize values are 64, 128, 256, 512, 1024, 2048, 4096 and 8192 in Vorbis I." Does that requirement only apply to block_0?
On 9/3/05, Tony O'Bryan <stormreaver@direcway.com> wrote:> For the Vorbis file I'm using to develop my decoder, I've read the Ogg header > at the start of the file, and now I'm reading the Vorbis identification > header. > > Everything checks out fine until I get to the block size byte (offset 28 > starting at the packet type field). The byte value here is 184, which is a > bit pattern of: 1011 1000. > > The low order 4 bits are 8. Squaring it gives 64. This is valid according to > the specs (as I understand them). The upper 4 bits are 11. Squaring it > gives 121. This is not valid according the the specs:I'm not quite sure where you got the idea that you should square this value (if something in the spec is unclear, let us know where, so we can fix it). The correct way to calculate blocksize is: blocksize = 1 << block_bits; For the cases you give here, that gives 1<< 8 = 256, and 1 << 11 2048, which are the standard values used by the reference encoder for 44.1kHz audio at most bitrates. Mike
On Saturday 03 September 2005 10:35 am, you wrote:> I'm not quite sure where you got the idea that you should square this > value (if something in the spec is unclear, let us know where, so we > can fix it).In section 4.2.2, the text for lines 7 and 8 say, "2 exponent (read 4 bits as unsigned integer)". This gave me the impression that the block size being read (call it "x") is finalized as x^2 (an exponent of 2) mathematically.> The correct way to calculate blocksize is: > blocksize = 1 << block_bits; > > For the cases you give here, that gives 1<< 8 = 256, and 1 << 11 > 2048, which are the standard values used by the reference encoder for > 44.1kHz audio at most bitrates.That makes more sense, and indeed gives me the correct values. :) On a tangent: It took some searching through various documentation files to find where I should start looking for information on writing a decoder from scratch, but once I found the starting point, I found the docs to be very helpful. Many thanks to whoever writes them.
> In section 4.2.2, the text for lines 7 and 8 say, "2 exponent (read 4 bits > as unsigned integer)". This gave me the impression that the block size > being read (call it "x") is finalized as x^2 (an exponent of 2) > mathematically.What you're doing works out to 2^x. To do x^2, it'd say "(read 4 bits as unsigned integer) exponent 2". Note that 1 << x is probably much faster than 2^x in hardware. -- Graham Mitchell - computer science teacher, Leander High School "Reading is to the mind what exercise is to the body." -- Sir Richard Steele _______________________________________________ Vorbis mailing list Vorbis@xiph.org http://lists.xiph.org/mailman/listinfo/vorbis
My mind just isn't focused on my email program today. Here's what I meant to send to the group the first and second times: On Saturday 03 September 2005 12:13 pm, Graham Mitchell wrote:> What you're doing works out to 2^x. To do x^2, it'd say "(read 4 bits as > unsigned integer) exponent 2".English and American are notoriously imprecise languages, so no assumptions can be safely made when there is any room for ambiguity. Putting "exponent 2" before or after the parentheses may or may not be intended to alter any given author's intent. The author may merely just be speaking an odd dialect as far as any arbitrary reader is concerned. On a personal note, I cannot recall having ever heard a shift operation expressed like that. A clearer statement would be something like, "(read 4 bits as unsigned integer); shift 1 left this number of bits."> Note that 1 << x is probably much faster than 2^x in hardware.Without question. However, there is nothing guaranteeing the reader that the specs are driven by raw speed at this point. All a new reader can do is to interpret the specs as written since he is not privy to the designer's private thoughts and intents, or to the benefit of retrospect.