similar to: FLAC metadata blocks and seeking

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

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

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,

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 wo 16 okt 2024 om 16:25 schreef Stefan Oltmanns <stefan-oltmanns at gmx.net>: > > Yes, overwriting the streaminfo total_samples number is a bit of a hack, > but it would only affect those files with more than 2^36 samples that > contains the special seek point, so no difference for the average flac user. > > Not sure how the applications actually read flac files, if they

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

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

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

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

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

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

Is it possible to place track markers that will be reflected in a cue sheet within a long FLAC file? I have a label who want to offer FLAC downloads of complete albums - but there have to be track points designated within the FLAC file How can I do this please? Many Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

Is it possible to place track markers that will be reflected in a cue sheet within a long FLAC file? I have a label who want to offer FLAC downloads of complete albums - but there have to be track points designated within the FLAC file How can I do this please? Many Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Fri, Jun 20, 2014 at 1:05 AM, lvqcl <lvqcl.mail at gmail.com> wrote: > I cannot find anything about the size of METADATA_BLOCK_PICTURE block > in <http://xiph.org/flac/format.html>. Where did you read this? > METADATA_BLOCK_HEADER has a 24-bit field to encode the length of METADATA_BLOCK_DATA ; hence the limitation (which not only applies to METADATA_BLOCK_PICTURE but all

Op di 15 okt. 2024 16:18 schreef Stefan Oltmanns <stefan-oltmanns at gmx.net>: > > I see, but that would require changes in the software using libflac and > require the file to be easily seekable to be able to skip to the end and > depending on how far away the seek points are, it could take a while. > No, seeking to a specific sample can take a while because of all the

On 12/11/06, Josh Coalson <xflac@yahoo.com> wrote: > --- Avuton Olrich <avuton@gmail.com> wrote: > > 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

(I am not on this list, please CC me manually if necessary) On Fri, Mar 15, 2002 at 11:47:15PM -0500, Asheesh Laroia wrote: > 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. FUD. Please stop that, it makes you look unprofessional. Until you 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

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