A few things about tape format... I'm not willing to be boring, I just want to be sure to understand the way things are working when everything's normal, because I'm currently struggling with complicated re-written loading routines... (I'm trying to adapt WAV2TAP to convert these re-written routines, but I wonder if there are not small differences that might prevent me from doing it).

So, open your Oric à Nu books at page 259 (or your 1.1 ROMs at E4AC), and WAV2TAP.C source code; here we go: we are now playing to the "correct me if I'm wrong" game

According to l'Oric à Nu, here's how I understand the loading process of a tape program in 1.1 ROM:
* First the Oric is searching for the synchro bytes (#16#16#16#16#16#16...), code in #E735:
- the Oric takes a bit from the tape
- moves a byte from 1 bit to the right, and adds the new bit
- as long as it's not #16, loop
- we have a #16, so the Oric is synched
- now take 3 bytes, see if they're #16 again. As soon as one of them is not, start the whole sync process again. If they're OK, continue.

So here we can draw this conclusion: the Oric needs FOUR CONSECUTIVE #16 bytes to consider the synch is ok: one to find the synch, and 3 to check the synch.

* Then the Oric loops, waiting for the #24 value, indicating the header beginning (code in #E4AC).

Here we can say that whatever there is between the four #16 bytes and the #24 bytes, the Oric will consider the program begins.
We could have the following values:
09 05 16 16 16 16 07 45 E2 A7 24 ...
the Oric would consider this is a correct synchro and load the bytes following #24 (header + program).

I'm no C expert, but here's how I understand it:
- get synched with #68 value (which is #16 with reversed bits, as they are stored on tape); loop as long as you don't find #68
- get 3 bytes, as soon as one of them is not #16, start the loop again (== start the whole sync process again), if they're all #16 then continue
- get rid of all the other #16 you could find
- as soon as another value is found, test it. It must be #24, if not, start the whole sync process again. If it's #24, then consider the program begins.

So with WAV2TAP, if I'm not mistaken, we MUST have the following consecutive values to consider the synch is OK: 16 16 16 16 24
The former example (09 05 16 16 16 16 07 45 E2 A7 24) would not load.

That means anyone that intentionally changed one of the four #16 values before the #24, or any error in the tape signal on these values, will prevent WAV2TAP from transferring the program, but won't prevent the Oric from loading it if the Oric found four #16 values somewhere before...

Now please tell me I'm wrong, if I was sure of what I'm saying I wouldn't ask
Cheers,
Simon

Now please tell me I'm wrong, if I was sure of what I'm saying I wouldn't ask

What a luxury of precautions, Simon
You are perfectly right, the behavior of Wav2tap is not correct...
I had coded this from memory, I thought that the synchro process would start from the beginning if a value different than $24 was read... I should have checked...

I guess that with that modification in wav2tap, you will be able to convert some of your tapes to .tap format, as they won't require the wav format anymore...

Some related info about the .tap format and how Euphoric handles it:

- Euphoric saves .tap with three $16 bytes, but it loads .tap as soon as one $16 byte is found. This comes from historic and compatibility reasons... Earlier Euphoric versions required three $16 bytes for the tapes to be loaded, because .tap files are already aligned to byte boundaries, so there's no need to synchronize with a first $16 byte... But Jeff had chosen to have only one $16 byte in his Amoric tapes, we had some debate at that time, I tried to convince him that having three $16 bytes was closer to the real thing because these three consecutive bytes are required before a $24... Also, these three $16 bytes followed by one $24 byte were a simple signature for .tap files, you could use this information on unix systems... As a result of our debate, I think he changed the number of $16 bytes output by Amoric when CSAVEing tapes to three (this has to be confirmed), but since some tapes on the Internet were already having only one $16 byte, I finally changed Euphoric to accept reading tapes having only one $16 byte...

- Looking back to these decisions, I now consider I have been wrong...
Even if a .tap is already byte -aligned, I should have added one $16 byte for a minimum total of four... The reason is that if you have a real tape, it will only load if it has that minimum of four $16 bytes... As a result, I'm not fully happy with the way tap2wav works: tap2wav accepts .tap files with a single $16 at the beginning and builds wav files that have 256
synchro bytes ($16). It would be better if tap2wav did no articificial transformation to the headers, this would allow to build very short wav files that the real Oric indeed loads (a small loader sent through a link from the PC, or from a MP3-player, would load in a fraction of a second). Of course, most tap files found on the internet only have three $16 bytes, so a strict conversion of these files would produce unloadable files (once again I should have chosen to have Euphoric write four $16 bytes

- Euphoric perfectly loads the tapes that have additional non-$16 bytes before the $24 start-byte, this is the good news. But tap2wav doesn't correctly handles them, I didn't imagine that different bytes could be inserted before the $24 byte when I wrote it... So, it seems it's time for a bug-fix release of the tape tools, isn't it ?
(and maybe an option to do a strict conversion would be a nice addition)

As a result, I made a few changes in WAV2TAP (to decode the modified routine, which actually reverses each byte's bit order in the tape signal), but I kept having problems, probably because of some errors in the synch just before the famous #24.
Anyway, little by little, I'm sorting all this out. Long article for the CEO-Mag some day

Euphoric saves .tap with three $16 bytes, but it loads .tap as soon as one $16 byte is found.

Hey, this is a valuable piece of information for 1K games competition, isn't it? 2 more available bytes can help.

As a result, I'm not fully happy with the way tap2wav works: tap2wav accepts .tap files with a single $16 at the beginning and builds wav files that have 256

Hehe, funny, I thought too about modifying it some day for my (old) PC/Oric tape communication link.

Euphoric perfectly loads the tapes that have additional non-$16 bytes before the $24 start-byte, this is the good news. But tap2wav doesn't correctly handles them, I didn't imagine that different bytes could be inserted before the $24 byte when I wrote it...

I also noticed something with tap2wav (I think we already discussed this once), and it's probably exactly the same problem: it doesn't like the "garbage" that can sometimes be found between 2 parts of a program that have been converted at the same time with wav2tap.
I have never taken the time to look at the source code about this; I suspect things are not so easy to handle (do we recreate a "clean" format, or try to deal with all the bytes as they are, even if they are garbage...)

So, it seems it's time for a bug-fix release of the tape tools, isn't it ?

I also wish I had the time some day to carry on the ",S" option for wav2tap. Some tapes are only recorded in slow speed (especially early ASN games), and transfering them is a boring process.
Also in this mode, as each bit is repeated X times (can't recall how many, 13 maybe), this could be used to minimize the loading errors.

I am trying to convert a wav file into tap without any success,
even though this wav loads correctly when I am using hardware tape in
Euphoric. The source code that comes along with the executable,
downloaded from oric.free.fr, has the same synchronize()
function as it is displayed in the Symoon's post. The symptoms I have,
wav2tap prints "Searching synchro..." and generates a null file, fit very
well to Symoon's concerns. I wonder, was there any release of tapetools with
the synchronize() function changed as indicated in this topic?

Symoon wrote:(do we recreate a "clean" format, or try to deal with all the bytes as they are, even if they are garbage...)

I think that the best thing to do is to keep the "garbage" (if it is intentional, not if it is due to bad recording) for two reason:
- Keep the "original thing"
- Prevent a possible copyright violation. Cleaning the byte stream is not an interoperability action per se. What I mean is that cleaning/removing a copy protection can be treated as interoperability and preservation.

Personally I don't care, it's just to be picky Preservation is in my opinion the most important, and although I think the majority of copyright holder doesn't care, when we saw cases as the one of "School Daze" it's best to be cautious.

Your confidence encouraged me to investigate it further and I found
the source of the problem. The wav I was having problems to convert
to tap was obtained as a save from Author. Probalby, Author is not
using the rom's load/save routines and, concequently, is not
recording the synchro and header that synchronize() is expecting. My
problem was solved when I commented all lines inside synchronize().

It would be nice the new version of wav2tap to have an option to disable
the searching for synchro and header.

vrozos wrote:The wav I was having problems to convert
to tap was obtained as a save from Author. Probalby, Author is not
using the rom's load/save routines and, concequently, is not
recording the synchro and header that synchronize() is expecting. My
problem was solved when I commented all lines inside synchronize().

It would be nice the new version of wav2tap to have an option to disable
the searching for synchro and header.

You're absolutely right about Author, I encountered the same problem while transferring old tapes from a former Oric programmer, he had Author saves.
So the only difference is in the synchonize part, that's a valuable piece of information, thanks