Displaying 20 results from an estimated 900 matches similar to: "Serious bug in FLAC"
2004 Sep 10
1
problems with flac?
So I recently encoded my entire CD collection (over
7000 songs) to flac and I have found that 18 of them
have a strange problem. The files are corrupted in
some way.. They will stop playing abruptly in the
middle of the song. I've attached a listing of the
metadata and you'll see what I mean.
You can see that the seek points toward the end have a
bunch of zeros and I'm not sure
2004 Sep 10
0
Serious bug in FLAC
Are you sure it's not your compiler? That's the first thing I would
check. I know that RedHat is famous for including broken pre-releases of
GCC in their distributions since 7.0.
I'd try recompiling with GCC 3 or GCC 2.95 (available as "kgcc").
-- Asheesh.
On Sat, 16 Mar 2002, Nick Lamb wrote:
> As far as I can tell I've found a serious bug in the command line
2024 Oct 14
1
C API: How to get a seektable for very long files?
Op ma 14 okt 2024 om 16:06 schreef Stefan Oltmanns <stefan-oltmanns at gmx.net>:
>
> Unfortunately that doesn't seem to be the case. I just made a capture
> that is > 30 Minutes with total samples set to 0 and a seek table: All
> players I tried cannot seek in the file and cannot determine it's
> length: VLC, Celluloid and DeaDBeef
>
> I wondered why I can
2024 Oct 14
1
C API: How to get a seektable for very long files?
Am 14.10.24 um 09:11 schrieb Martijn van Beurden:
> Op zo 13 okt 2024 om 22:33 schreef Stefan Oltmanns <stefan-oltmanns at gmx.net>:
>>
>
>>
>> The signal is the FM-modulated video signal of video tapes (like VHS).
>> The idea is to capture the signal directly from the video head amplifier
>> in the VCR and later demodulate/decode it in software, providing
2004 Sep 10
2
better seeking
When I was trying to find yesterday's xmms-plugin bug, i have noticed
that seeking in stream without seek-table isn't very good. With
attached patch it is much better.
--
Miroslav Lichvar
-------------- next part --------------
--- src/libFLAC/seekable_stream_decoder.c.orig 2003-02-26 19:41:51.000000000 +0100
+++ src/libFLAC/seekable_stream_decoder.c 2003-07-09 23:49:35.000000000 +0200
2007 Jul 25
3
FLAC: ERROR, MD5 signature mismatch
Hi
I have downloaded a FLAC file somewhere and when trying to decode it to WAV
it gives the error message: ERROR, MD5 signature mismatch
So my question is now: are FLAC files that give the error message above
still decodable to WAV (and how can you do this, because flac.exe doesn't
want to decode the file), even if there is a MD5 signature mismatch, or is
this not possible at all?
thx
2006 Oct 28
3
better seeking
Ok, the patch from 2003 about improving seeking still didn't make it
to CVS, so here is another try.
I made some benchmarking with the test_seeking utility from flac
sources to show how bad the current seeking is, especially without
seektable. Track used for the experiment had about 50 minutes.
In the following table is average number of seeks and number of
decoded frames required for one
2007 Jul 25
1
Bug: flac --replay-gain thinks that I used --no-padding
Josh Coalson <xflac@yahoo.com> wrote:
> --- Scott F <graue@oceanbase.org> wrote:
>
> > If I use flac to encode with the --replay-gain
> > option, I get a warning about the --no-padding
> > option...
> >
> > "NOTE: --replay-gain may leave a small PADDING block even with
> > --no-padding"
> >
> > ...even though I'm
2013 Jan 10
4
Fixing corrupt flac files
So, let's provide some information then :-)
----------------------------------------------------------------------------------------------
soa2ii at thor /mnt/files/music/Slime/Alle gegen Alle $ flac -aF 02\
St?rtebecker.flac
flac 1.2.1, Copyright (C) 2000,2001,2002,2003,2004,2005,2006,2007 Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome
2013 Jan 10
1
Fixing corrupt flac files
Here you are:
soa2ii at thor /mnt/files/music/Slime/Alle gegen Alle $ metaflac --list 02\
St?rtebecker.flac
METADATA block #0
type: 0 (STREAMINFO)
is last: false
length: 34
minimum blocksize: 4608 samples
maximum blocksize: 4608 samples
minimum framesize: 14 bytes
maximum framesize: 15637 bytes
sample_rate: 44100 Hz
channels: 2
bits-per-sample: 16
total samples: 5857656
2024 Oct 14
1
C API: How to get a seektable for very long files?
Op zo 13 okt 2024 om 22:33 schreef Stefan Oltmanns <stefan-oltmanns at gmx.net>:
>
> Is the seektable written at the beginning of the file in the metadata
> block or can there also be a second metadata block at the end?
>
Only at the start of the file.
>
> If it's at the beginning, would it possible to reserve space for N seek
> points and during encoding remember
2024 Oct 13
1
C API: How to get a seektable for very long files?
Op zo 13 okt 2024 om 02:16 schreef Stefan Oltmanns <stefan-oltmanns at gmx.net>:
>
> I cannot find any clues in the documentation how to write a
> seektable/reserve space for it.
> Can someone help me out?
>
There's actually quite a lot of documentation for this.
Please review https://xiph.org/flac/api/group__flac__stream__encoder.html#ga80d57f9069e354cbf1a15a3e3ad9ca78
2024 Oct 15
1
C API: How to get a seektable for very long files?
Am 14.10.24 um 16:30 schrieb Martijn van Beurden:
> Op ma 14 okt 2024 om 16:06 schreef Stefan Oltmanns <stefan-oltmanns at gmx.net>:
>
> I meant that when seeking to a certain sample, the stream decoder can
> in fact use the seektable despite not knowing a total number of
> samples. Of course, players, especially with GUIs, have to deal with
> not knowing a total number of
2024 Oct 13
1
C API: How to get a seektable for very long files?
Hi Martijn,
Am 13.10.24 um 21:00 schrieb Martijn van Beurden:
>
> There's actually quite a lot of documentation for this.
>
> Please review https://xiph.org/flac/api/group__flac__stream__encoder.html#ga80d57f9069e354cbf1a15a3e3ad9ca78
>
> I quote:
>> SEEKTABLE blocks are handled specially. Since you will not know the
>> values for the seek point stream offsets,
2005 Jan 25
0
bitbuffer optimizations
On Mon, Jan 24, 2005 at 06:31:21PM -0800, Josh Coalson wrote:
> yes, a mere 2 years later it is checked in!
>
> speed improvement for me is roughly 17% testing flac files on
> linux-i386.
Thanks!
In case you would like to check another old patch, I have attached updated
patch for seekable stream decoder, originally posted on 09/07/2003.
--
Miroslav Lichvar
-------------- next
2007 Jul 25
2
Bug: flac --replay-gain thinks that I used --no-padding
If I use flac to encode with the --replay-gain
option, I get a warning about the --no-padding
option...
"NOTE: --replay-gain may leave a small PADDING block even with --no-padding"
...even though I'm not using --no-padding. And the
file does end up with a small padding block, so
changing tags is slow.
I'd fixed this bug in my own copy of flac 1.1.4,
but forgot to submit the
2006 Nov 03
2
better seeking
On Mon, Oct 30, 2006 at 11:13:25AM -0800, Josh Coalson wrote:
> my apologies for not doing this before Miroslav... I will definitely
> integrate it this time.
Thanks. Sending latest version of the patch. Now it can seek in files
that have large id3 tag (or any random data) at the end and it won't loop on
streams with shuffled frames.
--
Miroslav Lichvar
-------------- next part
2024 Oct 13
1
C API: How to get a seektable for very long files?
Hello,
I'm using flac to compress s signal data during capture. The sample rate
is almost a thousands time higher compared to audio (40 MHz), resulting
in a lot of data very quickly.
I'm using the C API in my capturing application (mostly copy&paste
directly from the example) and it works so far, but unfortunately for
longer captures there is no seeking information. How can I tell
2004 Sep 10
4
bitbuffer optimizations
Ok, here is a patch waiting for new CVS :). It works fine for me, but
please check it before commiting...
--
Miroslav Lichvar
-------------- next part --------------
--- src/libFLAC/bitbuffer.c.orig 2003-01-30 17:36:01.000000000 +0100
+++ src/libFLAC/bitbuffer.c 2003-01-30 21:53:18.000000000 +0100
@@ -51,6 +51,25 @@
*/
static const unsigned FLAC__BITBUFFER_DEFAULT_CAPACITY = ((65536 - 64) *
2024 Oct 13
2
C API: How to get a seektable for very long files?
I think there is another major issue for me: In
METADATA_BLOCK_STREAMINFO the field for the length is only 36 bit,
that's not even half an hour at 40 MHz sample rate, resulting in that
the encoder sets it to 0 for longer captures. In the seekpoint the
sample number is 64 bit, which is more than enough.
But how does the decoder handle the seektable when the total number of
samples is unknown?