xiph
Documentation: the "Known bugs" webpage https://xiph.org/flac/documentation_bugs.html
The only bug listed is a behaviour that has later been changed because it doesn't make sense to even write seekpoints?
flac hasn't adhered to the tradition of listing known bugs in the man document, so that makes a case for such a webpage. I do think though, that several of the issues users may have are not outright bugs. Like how 1.4.0 rejects out-of-range signals (while some of these files, which do violate the spec, are even decoded as intended with 1.2.1) or ID3 tags. Users could be advised to try the application that wrote an offending file, to decode it and then listen carefully to the output (at low volume first).
I might try to draft such a text if it is welcome.
Apart from that, what are the known bugs? Inconsistent ".aifc" handling, and issue #808 if verified?
The only bug listed is a behaviour that has later been changed because it doesn't make sense to even write seekpoints?
The reason is that ffmpeg flac native encoder does not write SEEKTABLE?
No, this is something else - it is about Ogg FLAC. The 1.4.3 changelog says
No longer write seektables to Ogg, even when specifically asked for. Seektables in Ogg are not defined
The "bug" listed on https://xiph.org/flac/documentation_bugs.html is back to version 1.3.1, which behaves as follows:
When encoding to Ogg FLAC, the number of seek points is limited to 240.
But in the larger picture, this issue is about that web page. Which could maybe include compatibility issues, because some of those have arisen when various tools have written non-compliant files that all for sudden are rejected.
When encoding to Ogg FLAC, the number of seek points is limited to 240.
What is a seek point in this context? SEEKTABLE is inside flac or maybe even inside headerless flac. If ogg seek point on container level is what this is about do you still think ffmpeg should implement SEEKTABLE?
I think the web page should be removed.
Yes, there have been some changes in behaviour which are nice to document, but I don't think drafting it somewhere in the official documentation is necessary. I'm counting on people using search engines will end up on relevant forum topics discussing these issues.
No objections to removing the web page. Or there could be a wiki here or somewhere.
Looking at the other pages at https://xiph.org/flac , there is other information that is long obsolete and wrong. In more than one document, Sir Josh wrote -v for the verify option, that has been capital -V since ... who knows when. And https://xiph.org/flac/faq.html claims wildcards are not supported.
Outdated I think, is also the claim on https://xiph.org/flac/documentation_format_overview.html that the right prediction order gets inaccurately estimated above 9 or so. Nowadays -7 and -8 happily use -l12 without -e, and it's been years and years since the retune where -e was dropped from -8. Sure we we have kinda identified that it isn't fool-proof when the top octave is spectrally empty, -e is rarely of much use for CDDA.