This project has moved and is read-only. For the latest updates, please go here.

Invalid data while decoding

Mar 5, 2015 at 9:30 PM
Edited Mar 5, 2015 at 9:31 PM

I bumped into an issue while decoding an ogg file.


Message: Found invalid data while decoding.

Stack trace:
   at NVorbis.Ogg.PacketReader.AddPacket(Packet packet)
   at NVorbis.Ogg.ContainerReader.AddPage(PageHeader hdr)
   at NVorbis.Ogg.ContainerReader.GatherNextPage()
   at NVorbis.Ogg.ContainerReader.GatherNextPage(Int32 streamSerial)
   at NVorbis.Ogg.PacketReader.PeekNextPacketInternal()
   at NVorbis.Ogg.PacketReader.GetNextPacket()
   at NVorbis.VorbisStreamDecoder.TryInit()
   at NVorbis.VorbisReader.NewStream(Object sender, NewStreamEventArgs ea)
   at NVorbis.Ogg.ContainerReader.GatherNextPage()
   at NVorbis.Ogg.ContainerReader.Init()
   at NVorbis.VorbisReader.LoadContainer(IContainerReader containerReader)
   at NVorbis.VorbisReader..ctor(Stream stream, Boolean closeStreamOnDispose)
   at Dopamine.Core.Audio.NVorbisSource..ctor(Stream stream) in D:\Workspaces\VSOnline\Dopamine\Dev\Dopamine\Dopamine.Core\Audio\NVorbisSource.vb:line 23
   at Dopamine.Core.Audio.CSCorePlayer._Lambda$__1(Stream s) in D:\Workspaces\VSOnline\Dopamine\Dev\Dopamine\Dopamine.Core\Audio\CSCorePlayer.vb:line 77
   at CSCore.Codecs.CodecFactory.GetCodec(Stream stream, String filename)
This error looked similar to the one in this thread so I downloaded and compiled the latest code. However the issue persists.

The file which causes the issue can be downloaded here:!45256&authkey=!APRR1gdvb2w-8Bc&ithint=folder%2cogg
Mar 19, 2015 at 2:43 AM
D'oh!! The fix I pushed for the discussion you linked wasn't actually "spec-compliant". It should be correct now in latest source.

Sorry it took a while; I've been swamped with "real work". :)
Mar 20, 2015 at 6:45 AM
It works! Thanks for fixing it.
Apr 21, 2015 at 9:14 PM
Edited Apr 21, 2015 at 9:28 PM

While your latest commit fixed the issue for the previous file I posted, the issue remains for a new file I bumped into.

I've uploaded that ogg file to the same location:!45256&authkey=!APRR1gdvb2w-8Bc&ithint=folder%2cogg
Apr 22, 2015 at 2:41 PM
I'll look at it. Any changes will be pushed to Github, though.
Apr 22, 2015 at 2:51 PM
Thank you. I didn't notice you migrated to github. I just read the Home page right now :)
Apr 22, 2015 at 3:15 PM
Yeah, CodePlex is apparently getting less than useful levels of support from MS...

As far as your file, it would appear to be off-spec... The encoder set the "Continuation" flag on the first non-header page, which is invalid. Changing that byte (offset 79190) to "None" (0) fixes the decoding problem.

Here's the question, though: When NVorbis encounters this issue, what should it do? I think I should add a "Strict" flag (default to false) that indicates whether to throw an exception or to merely log a warning somehow. Either that or this particular issue should just be silently fixed in the Ogg packet code.

Apr 22, 2015 at 3:31 PM
Thanks for the quick response. So it seems encoders are not always following the spec. That is sad.

I've tested this file in audio players, and they could play it. So I would say NVorbis should also be able to handle the issue. In this case, as it's an off-spec issue, the flag makes a lot of sense (I can imagine someone wants to do some validation based on what NVorbis outputs): with the flag on NVorbis should throw and exception, with the flag off, NVorbis should work around the issue and play the file.

Did you have something like this in mind?
Apr 22, 2015 at 3:35 PM
That's the basic idea. It won't be something I put together quickly, though, because I'll have to dig through the full source to find all the places where "off-spec" should be caught and optionally warned.

For now, the work-around for this issue is to comment out line 133 of OggPacketReader.cs.
Apr 22, 2015 at 3:53 PM
Thanks for the work-around. I'll be testing it tonight. Are files which follow the spec still playable with this line commented out? I guess I'll find out as soon as I can get myself behind my development machine, but I was already curious.
Apr 22, 2015 at 3:56 PM
Yep, they should be fine. That line only checks the flag on the last packet and throws if the flags don't "match-up". Spec-compliant files will never trigger that error.