Page 2 of 2

Re: New tape fileformat (.ort)

Posted: Wed Oct 31, 2012 7:30 am
by Xeron
Thats weird, it should work. It may be that Oricutron didn't find the corresponding patch file for the ROM you are using...

Re: New tape fileformat (.ort)

Posted: Wed Oct 31, 2012 7:41 pm
by Dbug
I used the standard english rom, nothing special :)

Re: New tape fileformat (.ort)

Posted: Thu Nov 01, 2012 7:36 pm
by Xeron
did you have turbotape enabled?

Re: New tape fileformat (.ort)

Posted: Thu Nov 01, 2012 8:08 pm
by Dbug
Not sure? I did not do anything special:
- Started Oricutron
- Booted the DSK file
- Loaded the executable (basic) I wanted to save
- CSAVE "TEST.TAP"

Re: New tape fileformat (.ort)

Posted: Sat Jan 19, 2013 1:15 am
by Godzil
Symoon wrote:
Dbug wrote:Well, what would be a benefit would also if the code that read WAV would support all the variants of WAV, being mono, stereo, 8/16/24 bit per chanel, compressed or not. Because basically right now you can't just record with whatever tool you happen to have and save to whatever WAV format the tool uses by default: In my experience it's not going to work, meaning that archiving oric games is a science requiring years of experience and fiddling :p
I'm afraid this would be very hard to achieve. IIRC Fabrice chose 44kHz because at a lower rate, he wasn't able to decode 100% correctly the signal. The signal from the tape is so distorded and the tape players are using different speed, that it's really complicated sometimes to know how long each level lasts. For instance, that's one of the things that prevented me from finishing my slow speed decoder: I don't recall in detail but it worked with slow WAV files produced by Euphoric, but not with slow files from tapes (which makes it quite useless :? )
Stereo: another challenge, which channel will you use to read the WAV? Some tapes only have one channel recorded, the 2nd one being silent or so low that it can't be read. And belive me: some tapes use the left channel and, of course, other use the right channel :twisted:

It could be fun to store one program on the left channel, and another one on the right ;)

Re: New tape fileformat (.ort)

Posted: Wed Sep 04, 2013 9:35 am
by waskol
Hello !
A few years ago I suggested the use of such a new tap format ( http://forum.defence-force.org/viewtopic.php?f=22&t=365 ) in order to digitalize certain (protected ?) programs that could not be converted to a tap file, for instance : Side B of Tyrann, Cobra (snake game from Norsoft),

My idea was to be make it "readable" and editable by a real human too and easily readable by any emulator/tool since it was a text file of "0" and "1" put together by pairs.

May be it can be interesting to see it in Oricutron ?

Re: New tape fileformat (.ort)

Posted: Fri Sep 06, 2013 8:50 pm
by kamelito
waskol wrote:Hello !
A few years ago I suggested the use of such a new tap format ( http://forum.defence-force.org/viewtopic.php?f=22&t=365 ) in order to digitalize certain (protected ?) programs that could not be converted to a tap file, for instance : Side B of Tyrann, Cobra (snake game from Norsoft),

My idea was to be make it "readable" and editable by a real human too and easily readable by any emulator/tool since it was a text file of "0" and "1" put together by pairs.

May be it can be interesting to see it in Oricutron ?
Maybe off topic, back in the day 2 friends of mine wrote a program for the Oric, it was the ultimate tape copier.
It read the bit flow from the tape drive, stored it in memory then wrote it back to tape.
I think they only found one game that didn't work because it was too long to store in RAM.
They send it to Hebdogiciel back then but IIRC Hebdogiciel died before printing it too bad :(

Kamelito

Re: New tape fileformat (.ort)

Posted: Mon Sep 09, 2013 9:37 am
by waskol
Yes, that's a little bit the point kamelito...
The .tap format is designed to be a "byte-by-byte" encoding, that suits well for major oric tape recordings.
But the .tap format fails for some recordings that were done with some custom recording methods that do not use any header like those that are explained in various books (see for instance Geof Phillips : http://home.btconnect.com/geffers/files/chap4.htm )

Re: New tape fileformat (.ort)

Posted: Mon Sep 09, 2013 10:07 am
by ibisum
One thing I really want to learn is how to take a tape and save it on floppy .. I never understood this, but I guess I'm overlooking some tools/utilities to do it?

Re: New tape fileformat (.ort)

Posted: Thu Apr 23, 2015 2:53 am
by retroric
Xeron wrote:I have created a new format for Oric tape files.
(...)
ORT (Oric Raw Tape) files can contain raw square wave data for the tape input, as well as decoded bytes, and it can interleave the two.
(...)
I will also make a converter that can read .tap/.wav/.ort and save out .tap/.wav/.ort (any combination).
Hi Xeron,
I know I'm digging a 3-year old post and maybe you've moved on to other things by now, but I wanted to know whether you eventually managed to come up with the converter tool you mentioned that would be able to convert to and from between .tap, .wav and .ort ?

If so, can you please provide any links as to documentation or utilities that are available ??

The reason I ask is I use Oricutron a lot, unfortunately I'm not sure I really understand your .ort format well enough to be able to code an .ort to .tap converter myself.
Therefore I'd be very grateful if you could provide such a converter (Note: as to converting from .tap to .ort, in my view this has little value, as is providing a .tap to .wav converter since this is already catered for in Euphoric tools).

Cheers,

Laurent

Re: New tape fileformat (.ort)

Posted: Thu Oct 20, 2016 4:28 pm
by ThomH
It's even later now, but re: "the following bytes are encoded as standard Oric loader format" — to be complete, shouldn't a format at least specify fast versus slow encoding?

Re: New tape fileformat (.ort)

Posted: Sat Oct 22, 2016 12:03 am
by Xeron
No, it doesn't need to encode that.

Normal Oric data is stored in decoded bytes (same as .tap), so the fast/slow encoding has been stripped off. You could re-encode it as fast or slow if you like.

Other data is encoded as a waveform, so again no "fast" or "slow" really applies to the format.

Re: New tape fileformat (.ort)

Posted: Sat Oct 22, 2016 2:27 am
by ThomH
Xeron wrote:No, it doesn't need to encode that.

Normal Oric data is stored in decoded bytes (same as .tap), so the fast/slow encoding has been stripped off. You could re-encode it as fast or slow if you like.
Then any encoding scheme which relies on time passed won't work in .ort. But I'm splitting hairs. The file format can encode any square wave so clearly can handle anything an Oric can. It just would be an inefficient use of space were there ever an encoding that relied upon the one versus the other.

At the very least, would you be willing to say that it is always decoded as fast data, so that it's clear when a conversion tool would have to do something else?

Re: New tape fileformat (.ort)

Posted: Sat Oct 22, 2016 8:08 am
by Symoon
Not sure I understand all the questions, but some facts (and personal opinions):
- the "real" Oric tape routines headers do not store fast/slow flags, it is the user that decides if he wants to load fast or slow (,S), based on what the tape label (of his trained ears) says
- each emulator has its way to manage tape loading. Euphoric IIRC, with a TAP file intercepts ROM calls. If bytes decoding is called, then it loads bytes from the TAP file, whatever the speed. If bit loading is called, then it loads bits from the TAP file.
- fast or slow loading have no meaning in a TAP/ORT file where the bytes are already stored as bytes. Because emulator routines override the ROM routines.

But that doesn't mean it would be useless. I can see the following useful things in storing a fast/slow flag:
- let an emulator author choose if he wants the ORT file to load slower when "stored as slow" (a bit extreme as this can already be done using WAV files)
- indicate if the source of the ORT file was a slow or fast version on the original tape (this can be useful occasionnaly)
- prevent or warn the user of a multipart ORT file when converting it back into a FAST WAV, as the program may try to CLOAD"",S which will fail

But if an emulator tries to reproduce the exact real behaviour, beware that some users may not understand why, when they type CLOAD"", the (slow!) ORT file does not load. With TAP/ORT files, you have no more tape label or sound indication that the speed is slow or fast!

Re: New tape fileformat (.ort)

Posted: Sat Oct 22, 2016 12:53 pm
by ThomH
In response I'll also state my starting presumptions: a tape file format is a way of encoding an audio signal efficiently. The Oric senses only high or low so it's a one-bit signal. Most of the time the format is likely to hold data the ROM saved. In that case an efficient description is to list the bytes the ROM saved, making at least five out of thirteen implicit.

If you come at it from the efficient contextual storage of a square wave angle, it makes sense to differentiate between fast and slow encodings. This prompted the question.

I guess the mistake was in my assumption. The format is not intended to be an encoding of an audio signal — it's fine if different tools replaying the thing produce very different outputs. It's a way of interspersing segments of genuine audio within an emulator byte capture. It's about how to archive the software, not about how to archive the actual tapes.