Vorbis - Aug 2013 - Encoding using Fishsound + Vorbis = Strange "RoboCop" artifact

Hello Fellow-Vorbisites,

I've written a multi-track encoding/decoding library based upon fishsound.

Utilized Visual Studio 2010 to build 32-bit DLL's (Debug mode - no
optimization) of all the following:

libogg 1.3.1
libvorbis 1.3.3
libspeex 1.2rc1
libflac 1.2.1
liboggz 1.1.1
libfishsound 1.0.0

Currently testing under Windows 7 (64-bit).


Test Scenario:
=========Recording from two microphones simultaneously, creating two mono tracks
in
a single ogg file.

Using the exact same code to test fishsound with vorbis, flac, speex

The only variable that changes is the FishSound->format that is passed
into fish_sound_new().


Results:
=====If I use speex or flac, everything sounds sounds normal upon playback
(using Audacity for playback.)

If I use vorbis, my voice is recognizable, but I sound like a "robot"
-
some strange artifact is introduced that adds this "RoboCop" effect to
my
voice.

Samples can be downloaded at: http://tablet.brin.com/


Question:
======I'm trying to isolate the issue to either libvorbis or in libfishsound
(how it calls libvorbis in vorbis.c).

Any ideas on what would cause this artifact?

Thanks,
Bob

> Can you post a short sample of the resulting audio, and paste a snippet of
> the encoding code?
I've posted 5-second samples (one each of: vorbis, speex, flac) here:
>> Samples can be downloaded at: http://tablet.brin.com/
As for the code, I'm not sure how to do a snippet, since the test code is
in Java, calling a JNI-wrapper class, that in-turn invokes methods in a C
DLL, which in-turn invoke the actual fishsound methods.

I could post the source for the two java classes and the DLL on the web
site along with the samples, if that helps.

Bob

>I would check for any signed/unsigned mismatches and wrong data type sizes.
Thanks Tuomo - these are good thoughts. I will double-check this.

But since the same code produces acceptable Speex and FLAC files, wouldn't
those Speex/FLAC files also be affected by signedness/data-size issues?

>Then again, it might be the player is simply mishandling the multitrack
> data.

I played it back with both VLC (which appears to only recognize the first
track,) and with Audacity, and both players reproduce the Vorbis file with
the robo-artifact.

In Audacity, I was able to mute individual tracks, so I could isolate
playback of one track, and the artifact was on every track.


>
> Or...
> How about decoding the tracks separately to see if they are ok?
> This is is what my very old build of ogginfo reports:
> --- clip ---
> Processing file "VORBIS_testme1.ogg"...
>
> New logical stream (#1, serial: 00000001): type vorbis
> New logical stream (#2, serial: 00000002): type vorbis
> New logical stream (#3, serial: 00000003): type vorbis
> New logical stream (#4, serial: 00000004): type vorbis
> Warning: Vorbis stream 4 does not have headers correctly framed. Terminal
> header page contains additional packets or has non-zero granulepos
> Vorbis headers parsed for stream 4, information follows...
> Version: 0
> Vendor: Xiph.Org libVorbis I 20120203 (Omnipresent)
> Channels: 1
> Rate: 44100
>
This is interesting, so the last Vorbis header page (not the BOS header,
i'm guessing,)  has data packets in it? Or starts with a non-zero time
offset?

I'll look into that.  Thanks for pointing that out.

BTW, Streams #1 and #2 contain microphone captured input. Stream #3 and #4
contain silence (on purpose,) in case anyone notices.

Bob