I've been looking for a way to mount 7-Zip archives as virtual drives, similar to how IMDisk works with uncompressed disk images. At first I wanted a method where I could read and write to the virtual drives, but that proved to be too much so I settled for a read-only solution.
I found a free program called WinArchiver Virtual Drive. It supports 7-Zip, which is great. I tried it out and it was able to mount one of my archives as a CD drive. I navigated to the virtual drive and saw the contents of the archive. The problem was, when I tried to open a file, I saw a notice in the taskbar about an unsupported method, meaning compression method. The archive I had tried was compressed with LZMA2. I tried again with LZMA and it worked, but I didn't want to have to start using LZMA because it doesn't seem to compress as well.
I looked in the installation folder and saw a file called 7z.dll, dated March 24, 2010. I tried replacing it with a newer copy from my 7-Zip installation, but that produced an error.
Several weeks later, it occurred to me that I had tried to use a 64-bit DLL when the program and the original DLL were 32-bit. I had removed WinArchiver Virtual Drive so I reinstalled it and then went to the 7-Zip website and downloaded a 32-bit copy of 7-Zip.
Not wanting to replace my 64-bit copy of 7-Zip, I was able to open the installer EXE in 7-Zip and get the 32-bit DLL I needed. After replacing the DLL from 2010, Win Archiver was able to mount and read archives compressed with LZMA2.
Update:
The way WinArchiver Virtual Drive handles its cache seems flawed. First, if the archive is solid then the program has to extract the entire contents to disk. Having to extract the whole archive is perfectly normal if it's solid, but extracting to disk keeps you from accessing archives bigger than your free space. I can understand saving individual files to a cache, but even then it should ideally be done in memory if the files being accessed are small enough.
The other problem is that the cache is not cleared until you unmount the drive. The way the program works currently, if you mount a non-solid archive you can access files quickly like you'd expect, and they're stored in the cache. The problem is, each new file you access is added to the cache and if you run out of space, the program will give an error and refuse to access any more files. This brings us back to the first issue, where you can't make full use of archives bigger than your free space.
Sunday, September 23, 2018
Fully Decoded UTSC Packet
I released some UTSC packets for people to try and decode, to see if my format could be followed by other people. They contained a still image (instead of video since I don't have a VP9 encoder yet), music, an EPG, and some filecasts containing Bitcoin Cash blocks.
Tech2025 was able to extract the EPG but couldn't get any further. There was another guy, Jess, who he introduced to the format. I was pinged on Discord and asked to share some details. I brought Jess up to speed and provided him with the packets and the format documentation.
To be honest, I did help him a little, like with getting set up with a hex editor and explaining some of the byte structure. However, I let him do most of it so that we could honestly say he decoded it. The deal was that once someone decoded it, I would publish all the details of what was in the packets. I'm going to show what was in the first packet. This post will just describe the first one because the others are similar.
Recall that UTSC packets contain just 1 second of content.
The music is from Golden Alley, created by Nicolai Heidlas and Francesco Rea.
The EPG was a file called EPG0.json. It was contained within a 7-Zip archive compressed with PPMD.
Note: the EPG format is not defined so these are just suggested parameters.
The filecasts were split 7-Zip archives of the latest 3 Bitcoin Cash blocks at the time I created the packets. They were compressed with LZMA2. There is no need for me to share them here.
Finally, I wrote a UTSC parser in Liberty BASIC to show and extract all the information quickly. I didn't release it until after Jess had finished extracting everything.
Tech2025 was able to extract the EPG but couldn't get any further. There was another guy, Jess, who he introduced to the format. I was pinged on Discord and asked to share some details. I brought Jess up to speed and provided him with the packets and the format documentation.
To be honest, I did help him a little, like with getting set up with a hex editor and explaining some of the byte structure. However, I let him do most of it so that we could honestly say he decoded it. The deal was that once someone decoded it, I would publish all the details of what was in the packets. I'm going to show what was in the first packet. This post will just describe the first one because the others are similar.
Recall that UTSC packets contain just 1 second of content.
The music is from Golden Alley, created by Nicolai Heidlas and Francesco Rea.
The EPG was a file called EPG0.json. It was contained within a 7-Zip archive compressed with PPMD.
Note: the EPG format is not defined so these are just suggested parameters.
The filecasts were split 7-Zip archives of the latest 3 Bitcoin Cash blocks at the time I created the packets. They were compressed with LZMA2. There is no need for me to share them here.
Finally, I wrote a UTSC parser in Liberty BASIC to show and extract all the information quickly. I didn't release it until after Jess had finished extracting everything.
