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. > On 18 Jun 2025, at 08:33, brianw <bri...@audiobanshee.com> wrote: > > You can't get rid of --skip and --until > > All of the file formats that the flac command line supports are limited to 4 > GB or 2 GB, and there are hardware recorders that support recording directly > into FLAC. So, there would be no way to uncompress a 4 GB FLAC file without > some ability to extract only a subset. It's not a matter of editing, it's a > matter of accessing compressed files when the output formats are limited in > size. > > The only other way out would be to add support for a format like CAF that is > not limited to 2 GB or 4 GB files sizes. > > The options function well enough, because I've used them to convert files > that I've recorded on the Sound Devices 702 recorder. Of course, after I > learned my lesson, I set the 702 to stop recording at 1 GB or less, and jump > to a new file, so that the resulting FLAC files can always be uncompressed to > a valid WAV or AIFF. > > If there are still bugs in these options, then those bugs need to be fixed, > but removing the options is not a workable solution. > > Brian Willoughby > > p.s. Note that it's a common practice for recorders and players to deal with > file size limits by allowing a switch between files without dropping any > samples. Within the context of that common behavior, --skip and --until are > not "editing" commands, but merely a tool for lossless concatenation of audio. > > > On Jun 17, 2025, at 11:21 PM, Martijn van Beurden <mva...@gmail.com> wrote: >> Op di 17 jun 2025 00:11 schreef Stefan Oltmanns <stefan-oltma...@gmx.net>: >>> >>> Hi, >>> >>> I noticed the flac decoder has checks to disable the use of --skip and >>> --until if the total sample count is 0. >>> Why that? >> >> I've had to fix quite a few cases of undefined behaviour that were >> related to skip and until. The code is quite messy actually. I'd >> rather get rid of it completely, also since FLAC isn't meant as an >> edit tool (editing is not lossless and all) but I know some people >> depend on it. I'm pretty sure there are still some ugly bugs hiding in >> there. >> >> You could submit a pull request (or send a patch so I can do it) but I >> expect the CI will find something wrong with it. We could still try it >> anyway. > > _______________________________________________ > flac-dev mailing list -- flac-dev@xiph.org > To unsubscribe send an email to flac-dev-le...@xiph.org _______________________________________________ flac-dev mailing list -- flac-dev@xiph.org To unsubscribe send an email to flac-dev-le...@xiph.org
