search for: 35468950mhz

Displaying 4 results from an estimated 4 matches for "35468950mhz".

2024 Oct 15
2
C API: How to get a seektable for very long files?
...forms any other free lossless codec by a large margin, being 20% smaller and 10% faster than the next best (which was ffv1). The problem is the metadata, and not just total samples. We also can't put true values in the sample rate field because it doesn't have enough bits (I have files with 35468950MHz nominal sample rate for example), and there is no way to record that samples have been padded eg from 10 bits to 16 bits, which seems to be very common in SDR applications. These are just two examples off the top of my head - there are probably more. The problems around total samples and seek tabl...
2024 Oct 16
1
C API: How to get a seektable for very long files?
...forms any other free lossless codec by a large margin, being 20% smaller and 10% faster than the next best (which was ffv1). The problem is the metadata, and not just total samples. We also can't put true values in the sample rate field because it doesn't have enough bits (I have files with 35468950MHz nominal sample rate for example), and there is no way to record that samples have been padded eg from 10 bits to 16 bits, which seems to be very common in SDR applications. These are just two examples off the top of my head - there are probably more. > > The problems around total samples and...
2024 Oct 15
2
C API: How to get a seektable for very long files?
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
2024 Oct 15
1
C API: How to get a seektable for very long files?
...lossless codec by a > large margin, being 20% smaller and 10% faster than the next best (which > was ffv1). The problem is the metadata, and not just total samples. We also > can't put true values in the sample rate field because it doesn't have > enough bits (I have files with 35468950MHz nominal sample rate for > example), and there is no way to record that samples have been padded eg > from 10 bits to 16 bits, which seems to be very common in SDR applications. > These are just two examples off the top of my head - there are probably > more. > > The problems aroun...