Re: Encoding using Fishsound + Vorbis = Strange "RoboCop" artifact

>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