1

Closed

Some (other) Ogg files decode improperly

description

This has probably nothing to do with Issue 24 since the provided ogg file decodes properly now. I have, however, experienced problems with another ogg file.

There is some noticeable "clicking" noise in the beginning, which appears to be the result of decode errors in the first 256 samples. I get values around +/- 30000 which is definitely incorrect. When opening the same file with Audacity, the first samples have regular values close to zero.

file attachments

Closed Sep 16, 2013 at 3:55 PM by ioctlLR
Released

comments

Fetze wrote Sep 13, 2013 at 9:59 AM

Also, the second attached file is a perfect loop - but not when decoded with NVorbis, there is a noticeable clicking noise as well. This time, both start and end values seem to be messed up a little.

I have tested both files using an old, unmanaged OggVorbis implementation before, both worked well without any playback code changed.

ioctlLR wrote Sep 13, 2013 at 12:31 PM

DroneLoop.ogg appears to decode just fine for me. Audacity's imported version matches the NVorbis version perfectly.

LogoJingle.ogg definitely has a decoding error on the left channel for the first 125 samples. I'm not sure what the deal is, but I'll try to figure it out.

Thanks!

Fetze wrote Sep 13, 2013 at 1:19 PM

DroneLoop doesn't decode correctly; I'm using the currently available source code and modified TestApp to do some comparisons.

In the archive I've attached, you can see how DroneLoop.ogg looks like when imported in Audacity, which equals the decode using the current, unmanaged library. As you can see in comp1.jpg and comp2.jpg, both start and end of the stereo file are approximately (0.0, -0.25), so they match nicely when looping.

However, when reading out the file using NVorbis like the code segment from the archive states, I get Samples.txt as result. While starting samples are as expected (0.0, -0.25), the ending samples are not (-0.14, -0.18)

Fetze wrote Sep 13, 2013 at 1:21 PM

Update: I'm sorry, the DroneLoop issue was clearly on my side. There was an error in the code segment I used for comparison - it ignored the count variable, as you can see in report.zip.

ioctlLR wrote Sep 13, 2013 at 2:59 PM

Yep, the floor calculation wasn't clearing the residue when no floor energy is defined. In VorbisFloor.cs, look for Floor1.Apply(PacketData, float[]) and change the body to:
var data = packetData as PacketData1;
if (data == null) throw new InvalidDataException("Incorrect packet data!");

var n = data.BlockSize / 2;

if (data.PostCount > 0)
{
    var stepFlags = UnwrapPosts(data);

    var lx = 0;
    var ly = data.Posts[0] * _multiplier;
    for (int i = 1; i < data.PostCount; i++)
    {
        var idx = _sortIdx[i];

        if (stepFlags[idx])
        {
            var hx = _xList[idx];
            var hy = data.Posts[idx] * _multiplier;
            if (lx < n) RenderLineMulti(lx, ly, Math.Min(hx, n), hy, residue);
            lx = hx;
            ly = hy;
        }
        if (lx >= n) break;
    }

    if (lx < n)
    {
        RenderLineMulti(lx, ly, n, ly, residue);
    }
}
else
{
    Array.Clear(residue, 0, n);
}
I combined steps with some of more optimizations, and in this case forgot to do the "matrix multiply" with an empty floor if no floor energy is defined.

I'll get a bugfix release posted when I get a chance. Thanks for catching this one!

Fetze wrote Sep 16, 2013 at 5:27 PM

Works perfectly now. Thanks! :)