similar to: Serious bug in FLAC

As far as I can tell I've found a serious bug in the command line flac encoder :( I have created many hundreds of flac files and I was very annoyed to discover that the XMMS flac plug-in had intolerably long seek times, but since that had been mentioned on this list a bunch of times without anyone actually investigating, I thought I had better actually find the BUG which causes this. 1. I

Hello, Apologies if this has already been covered. I'm trying to compile FLAC 1.2.0 under FreeBSD without ogg support: when I run gmake, I get: encode.c: In function `convert_to_seek_table_template': encode.c:2181: error: structure has no member named `use_ogg' the following appears to fix the problem for me, although I've not checked it fully: ---

I just tried to build 1.2 on my Macbook i ran configure with the following arguments (like i have in the past) ./configure --enable-static --disable-asm-optimizations --disable-shared then "make: i get the following error: encode.c: In function 'convert_to_seek_table_template': encode.c:2181: error: 'struct <anonymous>' has no member named 'use_ogg'

sorry about the delay... first, yes you are calling it correctly. if your encoded files have max_framesize == 0, then that should mean that either 1) you were using the command-line flac to encode to stdout; or 2) you are using libFLAC directly. if 2, you can replicate the functionality that is in src/flac/encode.c:metadata_callback() to write back statistics and seek table to the metadata in

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

I have read FLAC's "--help", the man-page, and the HTML documentaion, but there are a few things that I don't understand. 1. I'll start with the thing I'm most confused about. The --best option is synonymous with -l 12 -b 4608 -m -e -r 6. Why is that? Is not -l 32 better that l- 12? And you can have -r 0,8 without using --lax, and -r 0,16 with --lax. 2. The --lax option

Op di 15 okt 2024 om 21:27 schreef Alistair Buxton <a.j.buxton at gmail.com>: > > I would like to see this kind of thing put into a secondary metadata block aimed specifically at SDR. This could be completely ignored by regular audio players - these files are not meant to be listened to anyway. I could probably figure out how to implement that, I even started looking into it once, but

Hi! I've been using a little C++ program I've written to encode flac files. The program does this in the usual way (I think), by inheriting a class from FLAC::Encoder::File, and passing it chunks of raw samples through process_interleaved()... Anyway, the program works beautifully, and I've now decided to try and add some metadata to the encoded flacs. Eventually, there will be vorbis

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

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

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,

On Fri, Jul 20, 2001 at 08:14:55PM -0700, Josh Coalson wrote: > --- Matt Zimmerman <mdz@debian.org> wrote: > > On Fri, Jul 20, 2001 at 10:51:11PM -0400, Matt Zimmerman wrote: > > > > > This version seems to work at least partially on ia64. I am able > > to encode my > > > usual test WAV file now, but I still get a segfault during the > >

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?

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

Hi all, A few (possibly dumb) questions about decoding.. 1. Is it possible to know the total size of FLAC metadata blocks in advance? Do I really need to parse all metadata blocks until I see the METADATA_BLOCK_HEADER with last-metadata-block == 1? 2. Is there a generally accepted best-practice for seeking if there is no seektable present in the file? The format states *"It is possible to

I'm attempting to decode part of a largefile flac whose seektable is broken or missing and the file is shorter then it's supposed to be, when I use 1.1.2 it decodes fine, when I use 1.1.3 it fails flac --decode --skip=719:58.0 --until=1024:58.0 -o \/home\/sbh\/work\/hs\/out.wav \/mnt\/ss\/sdb\/Sound\/Recording\/2006\-11\-29\/in.flac out.wav: ERROR seeking while skipping bytes

I'm attempting to decode part of a largefile flac whose seektable is broken or missing and the file is shorter then it's supposed to be, when I use 1.1.2 it decodes fine, when I use 1.1.3 it fails flac --decode --skip=719:58.0 --until=1024:58.0 -o \/home\/sbh\/work\/hs\/out.wav \/mnt\/ss\/sdb\/Sound\/Recording\/2006\-11\-29\/in.flac out.wav: ERROR seeking while skipping bytes

I've checked in code that supports a new metadata block called SEEKTABLE. Basically, it is an optional, arbitrarily-long list of seek points, by sample number and stream offset. I also added command-line options to flac so you can specify seek points by specific sample number and/or a specific number of evenly-spaced seek points. The table cost about 18 bytes per seek point. This seems to

Am 15.10.24 um 19:03 schrieb Martijn van Beurden: > > No, seeking to a specific sample can take a while because of all the > back-and-forth, but seeking to almost the end of the file is very quick. > > I know this is not the cleanest way, but as this only for the rare cases Ah, I see, because the frame header also include either the sample number (variable frame size) or the frame

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