Loading cassettes straight through line-in

[RokCoder]

I've been recording my cassettes as wav files and going through the various filtering, UEF creating paths with varying levels of success. Quite often I'm finding that I'm getting several blocks missing in most programs. I go back, twiddle with the volume and try again and those blocks are fine but other blocks are missing. I could splice these together with audacity or similar but what I'm wondering is - is there a better/easier way?

On the Beeb I would simply rewind the cassette and try the block again (maybe with a slightly tweaked volume or tone).

I was going to try to put a Windows app together that reads the cassette Beeb-style via the line-in. If it gets to a block that fails the CRC then it would simply instruct you to rewind and try that block again. When it's loaded the entire program it could save it as UEF or simply as a file to import into BeebEm or similar.

Am I reinventing the wheel here though? It seems like a fun project to make which is a big plus but it's also going to be entirely redundant if something already exists that does exactly this.

[geraldholdsworth]

Sounds like a good idea to me. Not sure if anything like this already exists.

[johnkenyon]

I was going to try to put a Windows app together that reads the cassette Beeb-style via the line-in. If it gets to a block that fails the CRC then it would simply instruct you to rewind and try that block again. When it's loaded the entire program it could save it as UEF or simply as a file to import into BeebEm or similar.

Rather than look for specific blocks, I would keep tabs of which blocks I have valid data for, read the header and data blocks, and then have the user rewind the tape to the beginning of the file for another go at filling in the missing blocks.

Store the captured data as follows:
one file named as per the original file, holding the captured data, with .1 .2 on the end to handle multiple identically named files.
one file named as above with .inf extension holding the Acorn metadata (load/exec/file attributes).
Third file ".hdr" containing information captured in the header block
Fourth file ".sta" containing information on the status of the data file - indicates the status of each block in the file - "missing", "collected with good CRC", "collected with bad CRC", "empty block" (aka b6 of block flag set)

Make the program capable of multiple passes (using the multiple files), and you could then have a program which would allow multiple passes with different tape decks to get a full capture.

If you've ever used ddrescue on a linux system to recover data from a scratched CD, you'll understand how that fourth file allows you to try and try again, using a different CD drive to recover data that the other drive couldn't pick out...

[RokCoder]

Rather than look for specific blocks, I would keep tabs of which blocks I have valid data for, read the header and data blocks, and then have the user rewind the tape to the beginning of the file for another go at filling in the missing blocks.

Yes to all of your previous comment - and thank you for the suggestions. It definitely makes total sense to store block data and block statuses regardless of overall outcome.

So I have now formulated a plan of action -

1. Try to implement a system that can read directly from line-in
2. Make it flexible and useful
3. Get further feedback and suggestions from stardot forums
4. Add a friendly UI
5. Have a cup of tea

[vanekp]

PlayUEF http://playuef.8bitkick.cc/will work a lot better as wave files being analog are very prone to causing errors with loading.
more info here https://github.com/8bitkick/PlayUEF

[RokCoder]

PlayUEF http://playuef.8bitkick.cc/will work a lot better as wave files being analog are very prone to causing errors with loading.
more info here https://github.com/8bitkick/PlayUEF

Doesn't PlayUEF do the opposite of what I'm wanting to do? I'm looking to convert from original cassettes into UEF files.

[vanekp]

PlayUEF http://playuef.8bitkick.cc/will work a lot better as wave files being analog are very prone to causing errors with loading.
more info here https://github.com/8bitkick/PlayUEF

Doesn't PlayUEF do the opposite of what I'm wanting to do? I'm looking to convert from original cassettes into UEF files.

then your title is confusing
then you need to load them in via the mic input I find works best, record them in a wave editor like goldwave, clean them up save them out as a 8bit mono wav file then use csw to convert them to a csw file then use makeuef to convert the csw into a uef file, sounds simple but its a lot more complicated than that if you want good clean original working copies, the fun starts when you come across the special copy protected games. besides all are available on line already in a uef format unless they are special tapes.

[RokCoder]

then you need to load them in via the mic input I find works best, record them in a wave editor like goldwave, clean them up save them out as a 8bit mono wav file then use csw to convert them to a csw file then use makeuef to convert the csw into a uef file, sounds simple but its a lot more complicated than that if you want good clean original working copies, the fun starts when you come across the special copy protected games. besides all are available on line already in a uef format unless they are special tapes.

I completely see what you're saying (and thanks) but it's not what I'm trying to do.

I'm archiving my own cassettes which contain a variety of my own programs, games I stripped the protection off, games with cheat modes I've added, etc. My issue is that I do what you've listed above and have problems with... well, it's described in my first post.

So what I'm wanting to create is the BBC cassette loading directly into a PC connected to a tape recorder. If a block fails the CRC check then you can simply rewind and retry that block, etc. (just like you would when loading straight into the BBC Micro).

I think the title is pretty accurate but maybe we'll agree to disagree on that one

[vanekp]

it all depends on the quality of the wav file (if they are of good quality converting them to uef also should not be a problem) as to how well it works, and your then limited as to where you can use them, one is what you are wanting to do load them back on original hardware, the only other thing that will load directly from wav files is MAME BBC emulator.
If you would like help converting them to UEF let me know, I don't mind helping out.

[RokCoder]

it all depends on the quality of the wav file (if they are of good quality converting them to uef also should not be a problem) as to how well it works, and your then limited as to where you can use them, one is what you are wanting to do load them back on original hardware, the only other thing that will load directly from wav files is MAME BBC emulator.
If you would like help converting them to UEF let me know, I don't mind helping out.

I do very much appreciate your offer of help but I don't think you're really seeing what I'm wanting to do here. Regardless of wave files I'm wanting to take my cassette recorder, connect it to the line-in and have my app build the UEF directly from the cassette that's playing. It'll be useful for me and also a fun (and educational for me) project to work on

[vanekp]

okay well good luck sounds like an interesting project. and I am sure someone else is busy with a similar project.

[geraldholdsworth]

I am sure someone else is busy with a similar project.

Isn't it always the way?

[tricky]

I don't know anything about this, but it seems that a recording, line in or mic depending on the output of your tape player should nearly always be good enough to convert successfully.
Maybe if you know audio processing, which I guess you may not or you would have already thought of this; improve the "parsing" of the analogue signal instead.
Anyway, your approach sounds like a nice little project and I hope you get all your tapes safely backedup and maybe you will share some too

[Coeus]

Am I reinventing the wheel here though?

There`s Quadbike: viewtopic.php?f=12&t=22846

There's a (DOS-based?) MakeEUF

See this thread: viewtopic.php?f=12&t=21968

and this manual: https://acorn.huininga.nl/pub/unsorted/ ... manual.pdf

[RokCoder]

Am I reinventing the wheel here though?

There`s Quadbike: viewtopic.php?f=12&t=22846

There's a (DOS-based?) MakeEUF

See this thread: viewtopic.php?f=12&t=21968

and this manual: https://acorn.huininga.nl/pub/unsorted/ ... manual.pdf

That's some very interesting reading - thanks!

I think there's still a niche for this and, even if not, I've got my proof of concept working and am going to use it to recover my own cassettes

It currently allows real-time analysis and reading from a cassette as well as capture to a wave file and parsing from wave files. Even if it's of no use to anyone else, it's proving both educational and fun to put together

[vanekp]

Indeed nothing wrong with that at all, and always good to have people come up with different solution's to a problem like this.

[RokCoder]

I've carried on chipping away at this tool in my spare time. Right now the UI and presentation are currently horrendous and there's plenty of work yet to do but this is where it's at -

Current features -

• Can load directly from cassette player connected to PC line-in
• Can load from wav files
• Fully uploaded files can be exported to file+inf for loading to DFS disk in BeebEm
• State of app can be saved and restored (so all files, data and states can be resumed)
• Autodetects if file already processed so you can rewind, tweak volume/tone or use different tape recorder and try again on any faulty blocks
• Displays successful block headers in green and successful block data in gold

Planned features -

• Wave display and editor so user can see and manually tweak any faulty bytes (defined by start bit, eight data bits and stop bit)
• Much nicer UI
• Manually or automatically adjust for phase
• Automatically adjust line-in level for loading from cassette
• Export to UEF
• Anything else that may be of use

Useful to others? No idea! Fun and educational to develop? Absolutely

[vanekp]

looking very good, I take it it cant handle any of the protected software titles.

[RokCoder]

looking very good, I take it it cant handle any of the protected software titles.

I'll need to dig a little deeper but protected files are still going to be bound by the two wave lengths so there's no reason I couldn't add the ability to read those files in.

Lock bits, control characters in filenames, data in headers, etc shouldn't be a problem (and will already be handled). I seem to remember that some protections changed the storage at a much lower level so they didn't bother with header blocks at all. If that's the case, I could read those in and, assuming data like that can be handled by UEF, export them to UEF - without header blocks and/or start and end bits for bytes then I'd have no way to perform error checking on the loads though.