search for: oltmanns

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 fo...

...all remain placeholders according to metaflac: FLAC__metadata_object_new FLAC__metadata_object_seektable_template_append_placeholders FLAC__stream_encoder_set_metadata (encoder init & loop) FLAC__metadata_object_seektable_template_sort Best regards Stefan Am 13.10.24 um 22:33 schrieb Stefan Oltmanns: > 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 >&g...

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 high...

Op zo 20 okt 2024 om 03:08 schreef Stefan Oltmanns <stefan-oltmanns at gmx.net>: > > I'm not sure what else there could be in "STREAMINFO_EXT" except for > total samples and sample rate, but maybe there is some other use for (at > least partially) backward-compatible flac extensions. > > Adding that to ffmpeg w...

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 sampl...

On Wed, 16 Oct 2024 at 00:18, Stefan Oltmanns <stefan-oltmanns at gmx.net> wrote: > Am 15.10.24 um 21:26 schrieb Alistair Buxton: > > Another SDR user here. It was me who reported the bug where total samples > > wraps around on overflow. > > That's a bug in the flac application. I think the correct behavior is &...

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, Cellulo...

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...

...roviding higher quality than traditional capture of analog video. See this project: https://github.com/oyvindln/vhs-decode/ I started to design a capture device, as there is no 40 MHz continuous sampling hardware available at consumer prices: https://github.com/Stefan-Olt/MISRC Best regards Stefan Oltmanns

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

Am 16.10.24 um 19:46 schrieb Martijn van Beurden: > libFLAC reads a file from start to back, and returns data to the > client as soon as it is done parsing. So, it first encounters a > streaminfo metadata block, sends that to the application, then starts > on the seektable etc. In fact, for a lot of applications, the seek > table is simply ignored because libFLAC uses it internally.

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...

Am 16.10.24 um 15:15 schrieb Martijn van Beurden: > > But how should such a number be presented to the libFLAC user? You > suggested overwriting the streaminfo total_samples number, but > streaminfo always precedes the seektable, so the streaminfo metadata > block is already parsed by the application before the seektable is > even read. Also, I think it is quite hacky to not pass

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 spec...

Am 15.10.24 um 21:26 schrieb Alistair Buxton: > Another SDR user here. It was me who reported the bug where total samples > wraps around on overflow. That's a bug in the flac application. I think the correct behavior is setting it to 0 if total samples > 2^36 > > FLAC performs extremely well on SDR samples, both speed and compression > ratio. In my testing it outperforms

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

...your case, where you need to skip a lot, I'd say you need to only store the frame sizes, compress them (streaming) with something like deflate or xz, and use the data (decompressed in a streaming fashion as well) to instruct skip ahead frame by frame. Op wo 16 okt 2024 om 00:53 schreef Stefan Oltmanns <stefan-oltmanns at gmx.net>: > > I think I have an even better idea now that definitely won't break any > decoder: > -Create a normal last seekpoint pointing to the very last frame. Total > samples should be that seekpoint + frame length > > To indicate that the last...

Hi, I am trying to create a logical volume storage pool with persistent device names for the block devices, because I can't/don't want to ensure that /dev/sd* names are persistent through reboots. virsh # pool-define-as web2067 logical - - /dev/disk/by-path/pci-0000:18:00.0-scsi-0:2:2:0 web2067 /dev/web2067 virsh # pool-build web2067 These two steps work as expected and the pv and the