Am 18.06.25 um 13:39 schrieb N. Jesper Larsson:
I don’t have any opinion on whether —skip and —until can or should be removed,
but I would say that the simplest way by far of getting rid of the necessity of
suport for picking parts of the input to decode would be to allow the decoder
to output raw PCM data. Of course, it puts the burden of keeping track of
number of channels, signedness, endianness, and padding bits on the user, but
on the other hand it gets really easy to compute file sizes, and split and
concatenate files with very simple tools. In my own code for writing and
converting raw files, I have the convention of placing the format specification
in the file name.
You could say that this is primitive, but there are advantages with each tool
doing only one thing. You can convert raw PCM to other formats using SoX for
instance (unless the bit depth is not a multiple of 8, which is required by
SoX).
About the details on the different variants that a raw file can contain, I have
this blog post:
https://klipspringer.avadeaux.net/ten-standard-ways-of-representing-binary-numbers/
J.
Of course decoding to raw PCM is possible (no matter the length of the
file) and then cutting with sox (maybe even using a pipe without a temp
file).
For normal audio this method don't have major disadvantages, but if you
have 200GB flac files (RF capture of several hours with 40 MHz sample
rate) this takes a *very* long time. If you want just a short snippet
from a specific point --skip and --until are several orders of magnitude
faster (a few seconds vs. a few hours) and are therefore highly useful.
And as I said I don't know of other tools that can do that.
I have created a pull request now:
https://github.com/xiph/flac/pull/838
My changes did pass all fuzzing tests that GitHub runs automatically.
Best regards
Stefan
_______________________________________________
flac-dev mailing list -- flac-dev@xiph.org
To unsubscribe send an email to flac-dev-le...@xiph.org
