[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
--- Barry Bouwsma <bugs@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk> wrote:> 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?seeking was not supporting in libOggFLAC until FLAC 1.1.1 also in FLAC 1.1.1 is the first official (i.e. correct) FLAC->Ogg mapping. for more info about the history of it see http://flac.sourceforge.net/ogg_mapping.html that might explain some of the problems. Josh __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250
[I'm not online regularly, so don't include me in any replies.] [ taken from the web-ified list archive, so References: header is missing the last Message-ID, sorry ] Figuring the flac@ list is more appropriate, I move this from the original location at vorbis@ to continue...> > 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> > That ogg123 wasn't able to recognize the file as something it> > if (len >= 32 && memcmp(buf, "OggS", 4) == 0 > > && memcmp(buf+28, "fLaC", 4) == 0) > > return 1; /* Ogg FLAC */> also in FLAC 1.1.1 is the first official (i.e. correct) > FLAC->Ogg mapping. for more info about the history of itThanks for the pointer. Having grabbed all the latest source a couple days ago and built everything new, I shall now pretend to have a better idea of what needs to be patched. The vorbis-tools/ogg123/flac_format.c seems to be unchanged, and can recognize neither the OggFlac 1.1.1 files newly created, nor those from my pre-1.1.1 source which pointed out the problem. (Is there a more appropriate list for ogg-utilities, say, ogg-dev@, to handle kitchen-sink applications like ogg123?) I've now patched flac_format.c in my copy of the ogg123 distribution based on the 1.1.1 description you pointed me to, and as an after- thought, added my hacks to recognize the unofficial mapping that I used to see, as well as the original code. (Was the original code to find `fLaC' at position 28 ever correct?) Here's my hack, in case someone who knows more about the history of the FLAC->Ogg mapping wants to rewrite it to be correct and apply it to vorbis-tools/ogg123/flac_format.c ... --- flac_format.c-DIST Sun Aug 22 20:33:25 2004 +++ flac_format.c Fri Dec 17 10:41:57 2004 @@ -96,13 +96,35 @@ int oggflac_can_decode (data_source_t *source) { +#if 0 /* Wooo, this ain't right, at least not now... */ char buf[32]; +#else /* XXXX the below is based on observation of a real file 1.1.1 flac */ + char buf[41]; +#endif int len; +#if 0 /* Wooo, this ain't right, at least not now... */ len = source->transport->peek(source, buf, sizeof(char), 32); if (len >= 32 && memcmp(buf, "OggS", 4) == 0 && memcmp(buf+28, "fLaC", 4) == 0) +#else /* XXXX the below is based on observation of a real file 1.1.1 flac */ + len = source->transport->peek(source, buf, sizeof(char), 41); + +/* single check if (len >= 32 && memcmp(buf, "OggS", 4) == 0 + && memcmp(buf+29, "FLAC", 4) == 0 + && memcmp(buf+37, "fLaC", 4) == 0) XXX */ + if ( (len >= 32 && memcmp(buf, "OggS", 4) == 0 + && memcmp(buf+29, "FLAC", 4) == 0 + && memcmp(buf+37, "fLaC", 4) == 0) +/* XXX HACK compatibility below with the original code, plus flac < 1.1.1 */ +/* my previous hack below */ + || (len >= 32 && memcmp(buf, "OggS", 4) == 0 + && memcmp(buf+28, "FLAC", 4) == 0) +/* XXX HACK original below; did this ever work? */ + || (len >= 32 && memcmp(buf, "OggS", 4) == 0 + && memcmp(buf+28, "fLaC", 4) == 0) ) +#endif return 1; /* Ogg FLAC */ else return 0; It still seems that seeking within the OggFLAC file within ogg123 does not work, and reading the source, probably doesn't work for speex files either.> > Out of curiosity, how easy should it be to implement > > seeking within an OggFLAC file, as opposed to a plain > > ordinary FLAC file?> seeking was not supporting in libOggFLAC until FLAC 1.1.1The deficiency is again in ogg123, flac_format.c , and probably needs to be hacked based on, say, the ovf_seek function, somewhat like I started, before I decided it needed more work than just modifying ovf_seek as a template. @@ -258,7 +280,27 @@ int flac_seek (decoder_t *decoder, double offset, int whence) { +#if 0 /* XXX Ugly HACK to see if we can get this working */ return 0; /* No seeking at this time */ +#else /* XXX */ + flac_private_t *priv = decoder->private; + int ret; + double cur; +#if 0 /* HACK stolen from ogg vorbis seek, but not ported to flac yet */ + if (whence == DECODER_SEEK_CUR) { + cur = ov_time_tell(&priv->vf); + if (cur >= 0.0) + offset += cur; + else + return 0; + } + ret = ov_time_seek(&priv->vf, offset); + if (ret == 0) + return 1; + else +#endif /* HACK stolen */ + return 0; +#endif } Hey, I just woke up. You expect me to come up with working code from nothing? Anyway, I may poke at it later, if my brain ever gets started. Or anyone else is welcome to come up with something. thanks barry bouwsma