Support for "solved" fluxmaps

[tdaede]

Both SCP and A2R have the concept of "raw" vs "solved" fluxmaps - the former are straight off a drive, the latter are suitable for writing onto new media. Fluxengine produces both - encoders will produce solved maps, and flux sources will produce raw maps. If we track this information in the Fluxmap, we can set the appropriate flags in the output files, as well as warn if a "raw" fluxmap is written with rawwrite.

[davidgiven]

That's a good idea, and easy to do --- it's just a flag.

Is it worth distinguishing between synthetic writeable fluxmaps (which I assume is what 'solved' refers to) and non-synthetic writeable fluxmaps? For example, formats which don't have a sector spanning the index marker should be writeable. The only issue is that there will be some quality degradation due to accumulated errors.

We'd probably also need an operation to convert a read fluxmap. This ought to be straightforward as it's just a decode/encode procedure, and most formats already have the information needed in the profiles.

[tdaede]

SCP and A2R have no such distinction, so I don't think it's important.

As an alternate path to doing a full encode and decode, I would like to add a "solver" to some of the decoders. This would basically rotate the fluxmap so that the index is over a blank area, realign bits with the PLL, and discard bits that are outside of a sector, but otherwise maintain the timing/gaps/etc. In particular, odd features like overlapped sectors would be preserved.

[d235j]

Is it worth distinguishing between synthetic writeable fluxmaps (which I assume is what 'solved' refers to) and non-synthetic writeable fluxmaps? For example, formats which don't have a sector spanning the index marker should be writeable. The only issue is that there will be some quality degradation due to accumulated errors.

I would say that A2R v3 has such a distinction, in the sense that a non-synthetic fluxmap would always be in an RWCP chunk, and a synthetic fluxmap would always be in a SLVD chunk. That said, A2R also has a minimum flux capture length, in timing captures in RWCP chunks, of 1.25 rotations, to guarantee overlap if there is a possibility of the a sector spanning the index. In reality, most non-synthetic fluxmaps will have multiple xtiming captures as that improves the chances of data recovery, so these will have to be reduced for writing anyway.

For formats that are index-aligned, I suppose one could trim data from an RWCP chunk to be index-to-index and stuff it into an SLVD chunk, but then the quality degradation issue would occur.

Note that an A2R can contain both RWCP (unsolved) and SLVD chunks.