TSX support in OpenMSX.

How did you manage that?
Even if we disregard the IPS overhead an 8-bit @ 4800Hz WAV should only grow with 4 bytes per bit, it comes down to 640 bytes.
Where does the other 300k come from?

I agree that my (lack of) explanation did not help, but imulilla gave a great explanation on why I think it is a good preservation of what would be the original digital master. Anyway, I think we all agree, TSX doesn't ultimately replace entirely anything and anything will replace TSX entirely as well... There are advantages to it (i.e.: same software, you can have a single hash even if created from different sources, as long as both were created from proper source, smaller source, can be converted back to a WAV that is good enough to be recognize by any system), there are disadvantages... And ultimately, I disagree (now, not with you, just talking about the general sense of the this conversation) that the ultimate advantage of having it integrated would be to stop getting people asking for it... There are good cases for its use, and while I ultimately am on the fence because I understand the OpenMSX team decision so far was not based on prejudice or thinking of not supporting because some childsh reason, but due to complex code, lots of line, they have limited resources and you have your team goals and means to work, to have something like this properly inserted it is not as simple as just merging what is working on a happy day scenario, you have to think about all unlikely scenarios, protect from those and so on. It would be cool to have it, but it is understandable to not have it officially now. Just hope this happens sometime.

I understand what you're saying. But I have to disagree on this small part of your full message.

Unfortunately when two people make a recording of the same cassette game. And then both convert their recording to TSX, there's a reasonable chance that both TSX files won't be 100% identical. Even if both TSX files work perfectly fine. In other words: there's no one true canonical TSX representation per game.

There can be multiple reasons for this:

• TSX is complex enough to have multiple valid representations for the same data. So multiple versions of the TSX creator tool may make different (all valid) encoding decisions.
• TSX can encode the (average) timing of the pulses. Two different recordings may have slightly different timings. Because the timing info is encoded very accurately (in Z80 cycles), even small differences can result in a different TSX file. As a workaround the TSX creator tool could ignore the actual timing and just encode standard (ideal) MSX timing.
• Between data blocks there usually is a period of silence. The length of this period is also encoded in the TSX file. But between recording the exact duration can (slightly) vary. Here it's not so easy to pick a 'standard' timing for silence (because e.g. if you pick a too low value, the MSX may not be ready yet to accept the next data block). A workaround could be to round up to the nearest 1/100s or 1/10s.
• TSX can optionally encode the signal level (high or low). Though for many encodings the actual level isn't important, only transitions between high and low matter. Some TSX creation tools may choose to specify the starting level anyway, others may leave it out.
• And then the obvious stuff like optionally encoding comments in the TSX file.

Many of the issues in this list can be worked around. For example not using comments and using the exact same version of the creation tool (with the same options) already helps a lot.

Anyway all this just to say that your statement "the same TSX-hash for the same software" is not always true.

It is difficult to follow the thread, many things are said and I suppose that some of them will miss answering it, besides that maybe do it in a disorderly way. First of all, highlight what Santiontanon says, that this is a hobby, it is to enjoy it
and it is done for free, which at the time it becomes an obligation or something annoying is not worth it.

It has been commented that the implementation of the format can be a cumbersome task, but as I already mentioned the code is already done for version 16, and I hope that soon it will be for version 17, which would not be the same as doing it from scratch; want see the possibility of doing it using something based on the tcl "cashandler", maybe it's easier.

The issue of fidelity to the original tape, I already said that the same tape could generate different WAVS, so I consider
that trying to take those WAVS as MASTER is not real, the only MASTER would be if a WAV was generated by capturing directly the audio of the machine that has the program in memory, using a format such as tape we will only get approximations of the MASTER, the problem is not the destination format (TSX), but the source format, which does not offer a 1: 1 representation of the MASTER; regarding the level it is the same, it depends on the volume used in the capture, I think it is not possible to know the volume original.

Regarding the equality between 2 TSX of the same game, if the edition is the same and the dump is correct, the blocks
of data will be equal at the CRC level, the CRC of those blocks is what we call DATA HASH, which will be the same on the 2 TSX ; in the web of "tsx.eslamejor" you can see how editions in which the content of the tape is the same the DATA HASH coincides.

That's not really relevant. If you want to patch Avenger for immunity, search for the sequence 3A F7 BD B7 C8 and change the C8 to C9; then search for the sequence 00 00 00 FF 28 and change the 28 to 29. It's not TSX-specific; it applies to the CAS version as well.

That's a fair point, but does Marty really have to store both his original and a patched WAV to invoke it every time he wants to play? Or convert it to TSX every time? That's an extra step that could be avoided.