![]() |
Working on Base-85 Encoder/Decoder Functions - Printable Version +- QB64 Phoenix Edition (https://qb64phoenix.com/forum) +-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1) +--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3) +---- Forum: Works in Progress (https://qb64phoenix.com/forum/forumdisplay.php?fid=9) +---- Thread: Working on Base-85 Encoder/Decoder Functions (/showthread.php?tid=2027) Pages:
1
2
|
Working on Base-85 Encoder/Decoder Functions - Dav - 09-23-2023 When I learned QB64-PE allows resources to be loaded from memory it re-kindled my interest in encoding methods to put small files in BAS code, like Base64 is used in several programs found here. One step more space efficient than Base64 is Base85 (also called ASCII85) which outputs smaller encoded data and uses a larger character set, so I started trying to figure it out. It's been a real challenge as I am not very math savvy and there were no BASIC sources of Base85 out there I could find to study. Here's what I have so far. This will take 4 bytes of binary data, convert it to an integer, divide that up and map them to a characterset, outputting 5 bytes of printable characters that can be included in BAS code. The decoder reverses the process. I have tested these functions on a few files, and they seem to encode/decode ok here - but they is VERY SLOW. If you would like to try them and/or add some improvements please do (Speed it up if you can). I'm also working on Base91 too, but it's not ready to post yet. - Dav Edit: Updated version. Now encode/decode much faster. Code: (Select All)
RE: Working on Base-85 Encoder/Decoder Functions - SMcNeill - 09-23-2023 Why not go from 64 to base-128? Everything from ASC(32) to ASC(160) should represent in the IDE with 0 issues, and all you'd need to do is convert from 8-bit to 7-bit data. RE: Working on Base-85 Encoder/Decoder Functions - Dav - 09-23-2023 That's an idea to play with. WIll give it a go. Would base-128 code post on forums ok? Maybe would need to skip the " chr(34) in the ide. The ` seems to be messing up posted code here lately when several are in a row, and the @ symbol was a problem on the old form I recall. Edit: Hey Steve - I just remembered something. Didn't you do a base-128 thing in a Christmas demo a few years back? I seem to recall a loooong one line code thing. I'm gonna look through my code stash! - Dav RE: Working on Base-85 Encoder/Decoder Functions - SMcNeill - 09-23-2023 Code: (Select All) SCREEN _NEWIMAGE(800, 600, 32) RE: Working on Base-85 Encoder/Decoder Functions - Dav - 09-23-2023 Oh cool - you posted what I was asking about in my edit post. Thanks! I will look those over. - Dav RE: Working on Base-85 Encoder/Decoder Functions - SMcNeill - 09-23-2023 https://qb64forum.alephc.xyz/index.php?topic=2017.0 -- There's where me and Petr played around with the encoding back in .net days. ![]() RE: Working on Base-85 Encoder/Decoder Functions - Dav - 09-23-2023 Thanks for the link! That must have been when I was gone for a while back then, or I sure would have remembered reading that! - Dav RE: Working on Base-85 Encoder/Decoder Functions - Dav - 09-23-2023 Steve, the Base-128 is the most space efficient yet. Will be great for stuffing files in code. A 256 byte input will output 293 byte encoded. My Base85 outputs 321 bytes for the the same input, larger. However, I seem to be getting an extra byte added converting 128 back to 256. Here's what I'm testing with... - Dav Code: (Select All)
RE: Working on Base-85 Encoder/Decoder Functions - SMcNeill - 09-23-2023 It's an extra 0 at the end from padding sometimes. I've corrected it already in the version under my name in Prolific Programmers. Think of it as the following 14 bites (two 7-bit "words"): 1111111 1000000.... Now, you can see where we'd make two 8-bit characters with those: 11111111 000000.. It's extra padding left over, giving us a stray 0 at the end, which I didn't notice and ignore in my math above. ![]() RE: Working on Base-85 Encoder/Decoder Functions - Dav - 09-23-2023 Thanks, Steve! I grabbed the newer ones you posted in your code area. Been testing it. The last byte is still decodes odd sometimes. I've narrowed it down to higher ascii input. Seems whenever the input data to be encoded contains ascii values of 128 or higher then the last byte of the decoded output will either be missing (only missing when 128 is present) or it's changed from the original (when 129 to 255 values). Everything is decoded perfect if input data is 0-127 only. - Dav |