Technology

59135 readers

2532 users here now

This is a most excellent place for technology news and articles.

Our Rules

Follow the lemmy.world rules.
Only tech related content.
Be excellent to each another!
Mod approved content bots can post up to 10 articles per day.
Threads asking for personal tech support may be deleted.
Politics threads may be removed.
No memes allowed as posts, OK to post as comments.
Only approved bots from the list below, to ask if your bot can be added please contact us.
Check for duplicates before posting, duplicates may be removed

Approved Bots

founded 1 year ago

MODERATORS

command line util to encode/decode framed packets? (lemmy.world)

submitted 3 months ago by nycki@lemmy.world to c/technology@lemmy.world

15 comments fedilink hide all child comments

I'm currently trying to set up a homebrew cassette tape storage format, but trying to use existing tech where possible. I was excited to see that minimodem already exists for converting an audio stream to a byte stream, and is even available in termux for android, so I could decode cassettes with my phone! However, I'd like some sort of higher-level tool to encode and decode "packets" or "slices" so that I can add error correction. I'm sure this sort of thing must exist for amature radio purposes.

I could write a script that cuts a file into slices, with checksums and redundancy for each slice, and then pads them with null bytes so I can isolate each frame when decoding. What I want is to find out if that's already been done. I've heard of AX.25 packets but I can't find a tool that does that with stdio.

you are viewing a single comment's thread
view the rest of the comments

[–] catloaf@lemm.ee 3 points 3 months ago (6 children)

Hmm... I think looking at this from a radio perspective isn't helpful. I found more resources when ignoring the media. Perhaps par2 or RAR would be useful? Generate error correction media first, then write to media.

Generally in radio, you could just request a retransmission, so I didn't find much from that angle.

You might also find something useful when looking at tape backup programs. You're not using LTO, but the principles are the same, so maybe there's some tooling that would be compatible.

[–] nycki@lemmy.world 1 points 3 months ago (2 children)

I did use par2 and tar to generate redundancy, but I still need a way to locate it in the bytestream. Tar doesn't seem to reliably mark the start or end of files :/

[–] tal@lemmy.today 2 points 3 months ago* (last edited 3 months ago)

Tar doesn't natively have an index to immediately seek to files in the tar archive, though I know that it's possible to extend it with an index somehow, because pixz will do a parallel LZMA compression that involves generating and using an index for tar archives.

EDIT: Oh, I think I see what you mean. You're saying that you want to use tar to store the redundancy files, not generate redundancy data for the file as a whole? Like, a tar of PAR2 files? I don't think that that'll work, because you'll want redundancy for tar's metadata too.

EDIT2: So what you want is a single bytestream with forward error correction, not a set of files that provide it.

kagis

It looks like this guy has an implementation, and says that he's using Reed-Solomon, but that it's also just his weekend project, so...shrugs

https://hack.systems/2018/05/16/redupe/

[–] catloaf@lemm.ee 1 points 3 months ago (1 children)

What are you using to control/access the tape? tar should handle that just fine, considering that's what it was originally made for.

[–] nycki@lemmy.world 1 points 3 months ago (1 children)

I'm using a regular off-the-shelf tape recorder, it doesnt have an electronic interface, I just press play and record manually.

[–] catloaf@lemm.ee 1 points 3 months ago (1 children)

So how are you retrieving files? Writing down timestamps? Tar should be able to find the start of an archive if you give it a little lead-in.

[–] nycki@lemmy.world 1 points 3 months ago

That's exactly what I thought would work, but it doesn't.

load more comments (3 replies)