* Block size. It is possible to get a common block size (like 512) from end of header. At worst, a decoder that understands 1001 might not find the same from end of header? [
* Similar for sample rate. There is a possible difference between accepting 1010 and accepting that one has to find 48 kHz from the end of header?
I don't think adding those would change much. Any reasonable encoder would not create such files (needless filesize increase) and any player that is able to read non-common blocksizes should work with this as well. Same for sample rate.
* Unknown total samples in stream info?
And:
* Testing how the players support or react to pictures (strange mime types?), cuesheets, gigantic padding, repeating metadata blocks, blah blah blah?
Even, it is known that some players want ID3 ...
I wouldn't include anything with ID3. The FLAC documentation strongly discourages using it, most FLAC tools won't work with them and including a file with ID3 might give people the idea that it is required/endorsed/supported. Testing an incomplete STREAMINFO block is a good idea. I'm not yet sure what tests to add for PICTURE blocks, the specification is not as clear as for the stream format, but I'll figure something out.
There was a case here where an Android decoder didn't seem to cope very well with different wasted bits values for different channels.
That should be tested with file 14. I just checked, about 1/3th of the frames has different wasted bit values for both channels.
About variable blocksize. Is it stated clearly somewhere in documentation that variable blocksize is "subset feature"? If this is not stated, how it was detected that it is "subset feature" actually?
No, it is not clearly stated, it is simply not listed as a limitation of the subset, much like a feature like wasted bits isn't excluded. There is, however, a diff from git that gave me the idea variable blocksize streams are meant to be subset.
Before this diff, format.html stated about the subset:
The blocksize bits in the frame header must be 0001-0101 or 1000-1110, specifying a fixed-blocksize stream (the exception being the last block as described in the table) and a few allowable blocksizes. This also means that the STREAMINFO metadata block must specify equal mininum and maximum blocksizes. If the sample rate is <= 48000Hz, the blocksize must be <=4608, i.e. blocksize bits 0001-0101 or 1000-1100.
After it, format.html stated
The blocksize bits in the frame header must be 0001-1110. The blocksize must be <=16384; if the sample rate is <= 48000Hz, the blocksize must be <=4608.
This was changed with the introduction of a 'blocking strategy bit'. Furthermore, looking at commit messages from the Flake encoder, it seems Justin Ruggles and Josh Coalson did some discussing. After this change, Justin removed the non-subset warning from Flake on encoding variable-blocksize streams.
And stupid question: what is difference in meaning between NOK and dash in wiki table?
The items with a dash weren't tested. The JVC KD-R871BT was in the car of a friend of mine, and I had little time to test. When the device froze on file with a non-standard blocksize, simply restarting didn't unfreeze the unit, I needed to wait for a minute. So, I hurried the rest of the testing a little. I will do more thorough testing later.