@Christian sorry I must have misread. So if the 55 is not what you call a "dummy byte" (that you added yourself), the file is correct.
Re-reading, now I understand you corrected the "bin2tap tool" you were taliking about, so it now calculates the end address correctly, avoiding to have to add a byte

As for the initial problem, the example file having vanished, I can't help there!

You're right it's an issue with the bin2tap tool and the fact that Euphoric and Oricutron handles the EOF differently.

The 55 is still what I call a dummy byte in case of a BASIC program because it's behind the last null byte and so not part of the program.
I think the end address should be 50F and not 510, but it's the way Oric does...

So, to create a BASIC tape file identical to one created by CSAVE, a bas2tap tool must compute the end address as:
End address = Start address + program length +1 (and add a dummy byte at the end of the file)

Aaaah ok, got it now! You are refering at the Basic program length, I was only considering the memory area saved.
Strange indeed.

I just made a test and Csaved a basic program, removed the last byte and changed the end address: it loads fine in both Oricutron and Euphoric - and runs fine (which means, if I'm not mistaken again, that a tool can "only" save the real data and the correct end address, it works, would it be basic or not).

For a BASIC CSAVE, the ROM routine (0xE7DB/0xE909) saves from where the text starts to where the variables start.

Thus every BASIC save has one extra byte of "junk" at the end (the first character of the name of the first variable, I think). But the save is still valid in that the header is followed by E + 1 - A bytes.