Bob Ingraham
2013-Aug-30 14:52 UTC
[Vorbis] 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
Bob Ingraham
2013-Aug-30 23:43 UTC
[Vorbis] Encoding using Fishsound + Vorbis = Strange "RoboCop" artifact
> 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
Bob Ingraham
2013-Sep-02 05:30 UTC
[Vorbis] 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