[Vorbis] Bug in ogg123 playback of OggFLAC files?

[Barry Bouwsma]

[I'm not online regularly, so don't include me in any replies.
 And I'm not sure if the vorbis or the flac list, or something
 else, is more suitable for the following, so bear with me]

Moin, moin.

I used a recent ogg123 to play back a FLAC file I had created,
and saw it wasn't able to seek within the file.  So, I thought
to myself, why not try out an OggFLAC file, so I created one,
using `flac --ogg', rather than oggenc or something else.

That ogg123 wasn't able to recognize the file as something it
should have been able to chew on.  So I dirtied myself in the
source code and found the following:

  if (len >= 32 && memcmp(buf, "OggS", 4) == 0
                && memcmp(buf+28, "fLaC", 4) == 0)
    return 1; /* Ogg FLAC */

Hmmm.  That's sorta like my fresh file from somewhat recent
source, but not quite:
00000000  4f 67 67 53 00 02 00 00  00 00 00 00 00 00 3d 59  |OggS..........=Y|
00000010  81 7a 00 00 00 00 31 e3  96 a9 01 30 46 4c 41 43  |.z....1....0FLAC|
00000020  01 00 66 4c 61 43 00 00  00 22 12 00 12 00 00 00  |..fLaC..."......|

Should the second line from the above code be a comparison
against the string "FLAC" instead, or should the "fLaC"
comparison be at position 34?

Changing the code to compare with "FLAC" results in a
binary that can play my OggFLAC file, whee.  But I still
can't seek.  The reason became clear when looking further
through the code...
  return 0;  /* No seeking at this time */
Whoops, bummer.

Out of curiosity, how easy should it be to implement
seeking within an OggFLAC file, as opposed to a plain
ordinary FLAC file?



Now, to sadder news:  I've been meaning to post a pointer to
some audio snippets that the default encoding of Vorbis makes
to sound much worse than the original.  It's the voice of the
late John Peel from his last radio shows on the BBC, where it
sounds as if there's a lot of overload distortion going on in
the original WAV file (48kHz sample, decoded from the MPEG
layer 2 audio broadcast via satellite direct into an S/PDIF
input), and when it gets compressed by oggenc, it sounds to
me as if the sound is sent through a hollow tube or something.

These compressed files are where I first noticed this significant
difference between the original and the compressed version, while
the music and just about everything else apart from the speaking
does not suffer from this effect, which I initially attributed
to the overloaded sound.

Then recently I made another recording of spoken material from
a different BBC channel, of an old (undoubtedly mono) program,
that I chose to encode both as stereo (looking at the raw audio
samples, it was not a monaural broadcast) and downmix to mono.

Listening to the resulting files I noticed the same effect in
the compressed stereo file, that was absent in the downmixed
file, so now I hypothesize that this effect is due to some
phase variation between the two channels, or whatever it is
that is causing the difference between each left and right
channel sample in sources that are supposedly mono.

(For all I know, this could also be peculiar to the particular
receiver I use, although viewing sinus wave test tones that
appear to be sent as stereo does not show as significant a
difference between the left and right samples at any given
point in time.  I haven't played around to see how different
hardware affects these broadcasts yet.)

Note that I've done nothing more than observe this so far;
I haven't tried encoding this material at different quality
levels to see how it sounds, nor have I analyzed the audio
data for phase or other differences -- all I have is a simple
script that shows the numeric values of the samples in the
PCM data, which I then eyeball.


Anyway, if someone would want a short sample of this to play
with or analyze and see what is going on, I can put a short clip
up with this material, as well as the results of my attempts to
encode it.


thanks
barry bouwsma