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 number (fixed frame size). I assumed the stream would have to be decoded from the point of the last seekpoint to the end
There are already a lot of applications reading FLAC, with and without libFLAC. Changing behavior and the spec like this is going to break some of them, because the changes you propose also affect files with fewer samples. total samples being 0 can and does happen for files that were created by a streaming encoder for example.
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 seekpoint is pointing to the last frame, there should be two placeholders: First has the offset set to ASCII "TOTALSMP", the next one all zeros. That some encoder adds placeholder seekpoints with that pattern just by chance is almost 0. When the decoder scans the seekpoints, the total_samples is 0 and if it detects that two placeholders it will set total_samples to that value. I don't see an issue with that? Old files are treated by new decoder just like before, new files are treated by old decoder also just like before, only new file and new decoder will result in that feature. And this only affects files with more than
So, adding an API function that applications need to adopt is a feature, not a bug. I really don't want to modify existing behavior when it is not strictly necessary.
I'm not saying a new API call is a bug. But as this is such a niche case, that I don't think many programs will incorporate that feature, because the need is not seen (and being able to open the file in an audio player for quick check and random points is a great feature). If libflac just returns the correct total sample value you can just recompile libflac on your system and it will work. Additionally I think there is one issue: there are only 31 bits for the frame number, with a frame size of 4096 this is "just" 2^43 samples, which maybe not enough in every case (SDR with higher sample rate?), and smaller frame sizes are possible. And for variable block length it's again 2^36. Of course in combination with the last seekpoint this could work, but without a seektable it's again problematic. Best regards Stefan _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
