IndexOutOfRangeException for this OGG file since v0.10.0-alpha about nvorbis HOT 5 CLOSED

I think I found the problem. It looks like the last page of that OGG file contains 0 packets and neither PacketProvider.GetNextPacket(ref int pageIndex, ref int packetIndex) nor PacketProvider.CreatePacket(..., int packetCount, ...) handle this case.

This is the complete page as received by PageReader.ParsePageHeader(byte[] pageBuf, int? streamSerial, bool? isResync):

Immediate Window> pageBuf
{byte[28]}
    [0]: 79
    [1]: 103
    [2]: 103
    [3]: 83
    [4]: 0
    [5]: 4
    [6]: 127
    [7]: 93
    [8]: 8
    [9]: 0
    [10]: 0
    [11]: 0
    [12]: 0
    [13]: 0
    [14]: 106
    [15]: 191
    [16]: 203
    [17]: 22
    [18]: 17
    [19]: 0
    [20]: 0
    [21]: 0
    [22]: 96
    [23]: 189
    [24]: 234
    [25]: 244
    [26]: 1
    [27]: 0

I think the last page byte (pageBuf[27]) technically is some page data, because the header only uses the first 26 bytes (right?), but I assume it's some kind of terminating 0 byte?

from nvorbis.

I did a little reading into the OGG format (maybe I should have done this before creating the PR 🙈), and I found out that pageBuf[26] tells us that there are 1 segments in the segments table. The table entry for that segment at pageBuf[27] in turn tells us that this segment has a size of 0 in the page body.

So for full disclosure, I have no clue where that "page body" is located and thus I'm totally unsure if there is a cleaner way to handle such a segment.

from nvorbis.

Wow, that's a fun one... So the file is actually invalid. Ogg does support empty pages, but the final page of a Vorbis stream cannot be empty (it must have EOS set and have just the final packet in it). Adding up the pageBuf[26] bytes following offset 26 should give a positive value, and the final byte cannot be 255. Following that should be a count of bytes equal to the sum of the previous calculation (pageBuf[26 ... 28] = {2, 255, 21} would have a total page length of 27 + 2 + 276 = 305 bytes).

I'll have to play with this a bit to figure out how to cleanly support the file in question. Probably the simplest is to make the packet logic skip the page if zero length... Both readers will need to be updated, though.

from nvorbis.

Check out PR #8 for a possible fix. It seems to work fine for me.

from nvorbis.

I just tried the fixed master branch and it works fine. Thanks!

from nvorbis.