I had a VCD which was burnt into a DVD when VCD players went out of use. Now I want to create backups of that DVD; so I'm trying to copy the files from the DVD ... it's mostly empty - only one 'VCD' folder contains ENTRIES.VCD and INFO.VCD files, and an 'MPEGAV' folder contains a .DAT file.
When I try to copy the .DAT file, the copy starts, but halfway through the progress bar, I get an error saying "can't read from the source file or disk". How do I go about creating a backup of the CD?
How do I go about creating a backup of the CD?
There are a few ways to go about this. My first suggestion would be, if it's a video DVD (that would go in a DVD player), you can try Handbrake. It has many options to convert the video from an encoded DVD into a portable video file (AVI, MPG, etc.).
Another more technical option is to make a byte-for-byte copy of the disk, ignoring any actual files there. This preserves the file system table which is important for it to continue playing in a DVD player. imgburn is good for this. Specifically, you could read the disc to an ISO image and then write that image to any new disks.
Lower level tools you could use include: if you use Linux, dd. If you use dd, exercise caution -- it is a very powerful tool. You could use clonezilla for this as well, and it's OS-independent, but the instructions.
Related
macOS HFS+ supports transparent filesystem-level compression. How can I enable this compression for certain files via a programmatic API? (e.g. Cocoa or C interface)
I'd like to achieve effect of ditto --hfsCompression src dst, but without shelling out.
To clarify: I'm asking how to make uncompressed file compressed. I'm not interested in reading or preserving existing HFS compression state.
There's afsctool which is an open source implementation of HFS+ compression. It was originally by hacker brkirch (macrumors forum link, as he still visits there) but has since been expanded and improved a great deal by #rjvb who is doing amazing things with it.
The copyfile.c file discloses some of the implementation details.
There's also a compression tool based on that: afsctool.
I think you're asking two different questions (and might not know it).
If you're asking "How can I make arbitrary file 'A' an HFS compressed file?" the answer is, you can,'t. HFS compressed files are created by the installer and (technically[1]) only Apple can create them.
If you are asking "How can I emulate the --hfsCompression logic in ditto such that I can copy an HFS compressed file from one HFS+ volume to another HFS+ volume and preserve its compression?" the answer to that is pretty straight forward, albeit not well documented.
HFS Compressed files have a special UF_COMPRESSED file flag. If you see that, the data fork of the file is actually an uncompressed image of a hidden resource. The compressed version of the file is stored in a special extended attribute. It's special because it normally doesn't appear in the list of attributes when you request them (so if you just ls -l# the file, for example, you won't see it). To list and read this special attribute you must pass the XATTR_SHOWCOMPRESSION flag to both the listxattr() and getxattr() functions.
To restore a compressed file, you reverse the process: Write an empty file, then restore all of its extended attributes, specifically the special one. When you're done, set the file's UF_COMPRESSED flag and the uncompressed data will magically appear in its data fork.
[1] Note: It's rumored that the compressed resource of a file is just a ZIPed version of the data, possibly with some wrapper around it. I've never taken the time to experiment, but if you're intent on creating your own compressed files you could take a stab at reverse-engineering the compressed extended attribute.
First, full disclosure: I'm very new to coding and very new to file dissecting, but its something I anticipate studying in school very soon, so please pardon my ignorance in future interactions.
As a project I've decided to dissect the files of a mobile app I greatly enjoy. This app is Futurama: Worlds of Tomorrow. I'm a big fan of the cartoon, even spent money on the stuff, so I figured it was natural for me to pick.
Extracting the .apk file was easy, I found some of the assets they use in the game, like the music, the soundbytes, and some .pngs. All simple stuff.
However there are two files I'm absolutely baffled by: files with an .astc.czz extension and an .ita file that is not an italian read me file, the developers informed me that those are animation files.
Allow me to go into what I know and what I don't know:
Filename.astc.czz
Example file here
I recognize .astc as a compression file and was informed that .astc files are common for mobile games. Fair enough, but the real extension is .czz, the "real" extension of the file leads me to dead end. I've found the ASTC Evaluation Codec
by ARM-Software on github so I tried that. I changed the extension to .astc and then tried keeping .czz but the codec gives me an error every time. This is where I show my ignorance, I didn't know the right way to do this so I'm showing you every combination of what I tried. I replaced my name with user.
C:\Users\user\Downloads\astc-encoder-master\Binary\Win32
λ astcenc -d C:\Users\user\Downloads\astc-encoder-master\Binary\Win32\AC0001-dialogue1-003#2x.astc C:\Users\user\Downloads\astc-encoder-master\Binary\Win32\AC0001-dialogue1-003#2x.tga
File C:\Users\user\Downloads\astc-encoder-master\Binary\Win32\AC0001-dialogue1-003#2x.astc not recognized
C:\Users\user\Downloads\astc-encoder-master\Binary\Win32
λ astcenc -d AC0001-dialogue1-003#2x.astc AC0001-dialogue1-003#2x.tga
File AC0001-dialogue1-003#2x.astc not recognized
C:\Users\user\Downloads\astc-encoder-master\Binary\Win32
λ astcenc -d C:\Users\user\Downloads\astc-encoder-master\Binary\Win32\AC0001-dialogue1-003#2x.astc.czz C:\Users\user\Downloads\astc-encoder-master\Binary\Win32\AC0001-dialogue1-003#2x.tga
Failed to open file C:\Users\user\Downloads\astc-encoder-master\Binary\Win32\AC0001-dialogue1-003#2x.astc.czz
C:\Users\user\Downloads\astc-encoder-master\Binary\Win32
λ astcenc -d AC0001-dialogue1-003#2x.astc.czz AC0001-dialogue1-003#2x.tga
Failed to open file AC0001-dialogue1-003#2x.astc.czz
No success there.
So then I learned that .CZZ files are apparently associated with visECAD Viewer and I downloaded that and the .astc.czz files became associated with the program. I tried opening them but visECAD says it cant open them because they are "outdated." So that's another dead end.
Right, so that's all I know.
Filename.ita
Example file here
Out of curiosity I've actually emailed the developers about this file (and the astc ones too) and they said those are the animation of the game. They couldn't send me a viewer, which is perfectly fine, but I don't even know what .ita files are associated with that aren't italian read me's. Any insight would be appreciated, the animations are great and I would love to see them.
For full disclosure here are snippets of what the developers sent me:
Those strange file types are actually compressed files (like
".astc.ccz"). Different devices use different compression methods, so
we support many types to maintain low storage and memory usage. Some
devices don't use compression and just use .png versions of the same
file names.
The .lta files are the game's animations. I wish I could help you out
with viewing them, but there's no way for me to send you a viewer. :(
Well that's all folks, sorry it was so long, and thank you so much in advance. I'm grateful already!
I realise this is a few months old, but in case you're still interested, I've just cracked it. Basically, it's a compressed texture, the ccz part being the compression, and the astc being the texture format. I managed to decompress the file using QuickBMS (http://aluigi.altervista.org/quickbms.htm), using the following script for ccz files (copy the following into a txt file):
endian big
comtype zlib_dynamic
get ZSIZE asize
math ZSIZE - 0x10
get NAME basename
idstring "\x43\x43\x5a\x21"
goto 0xc
get SIZE long
clog NAME 0x10 ZSIZE SIZE
On running QuickBMS, it will first ask for a script, upon which point it to your new txt file. Then it will ask for the file you want to decompress, point it at your ccz file. Then it will ask where you want to save your astc file.
Now you will need a program that can open astc files! I used this one, Noesis: http://www.richwhitehouse.com/index.php?content=inc_projects.php&showproject=91
Find your astc file (the interface is quite straightforward), then from there you can double click the file to open it, then right-click and export to a variety of formats. For proof of concept, here is the extracted pf0001-action5-001#4xout (PF being Philip Fry I assume). https://www.dropbox.com/s/t2l3mesi2psbd1p/pf0001-action5-001%404xout.png?dl=0
Both programs allow for batch processing as well, so you should have everything you need! However, the lta files are skeletal animation I believe, so unfortunately the character animations are all in pieces. However, I'm looking into that next. Hope this helps!
EDIT: The above information is useful for your specific query, i.e. decompressing and reading the contents of those files. HOWEVER, if your end goal is to view the assets of the game, it's worth knowing that many of the assets are only downloaded AFTER the game is run, so looking in the "com.tinyco.futurama" on your Android voice will show all kinds of assets not present in the apk file. Many of them will be ready-extracted as well, being made ready for gameplay, so I would highly recommend copying the contents of this folder periodically. I think it re-compresses unused assets as well, so I would copy out the ccz files also, then either way you should reap the maximum benefits.
In a Windows 8 Command Prompt, I had a backup drive plugged in and I navigated to my User directory. I executed the command:
copy Documents G:/Seagate_backup/Documents
What I assumed was that copy would create the Documents directory on my backup drive and then copy the contents of the C: Documents directory into it. That is not what happened!
I proceeded to wipe my hard-drive and re-install the operating system, thinking I had backed up the important files, only to find out that copy seemingly concatenated all the C: Documents files of different types (.doc, .pdf, .txt, etc) into one file called "Documents." This file is of course unreadable but opening it in Notepad reveals what happened. I can see some of my documents which were plain text throughout the massively long file.
How do I undo this!!? It's terrible because I was actually helping a friend and was so sure of myself but now this has happened. The only thing I can think of doing is searching for some common separator amongst the concatenated files and write some sort of script to split the file back apart. But then I would have to guess the extensions of each of the pieces...
Merging files together in the fashion that copy uses, discards important file system information such as file size and file name. While the file name may not be as important the size is. Both parameters are used by the OS to discriminate files.
This problem might sound familiar if you have damaged your file allocation table before and all files disappeared. In both cases, you will end up with a binary blob (be it an actual disk or something like your file which might resemble a disk image) that lacks any size and filename information.
Fortunately, this is where a lot of file system recovery tools can help. They are specialized in matching patterns. Specifically they are looking for giveaway clues to what type a file is of, where it starts and what it's size is.
This is for instance enabled by many file types having a set of magic numbers that are used to allow a program to check if a file really is of the type that the extension claims to be.
In principle it is possible to undo this process more or less well.
You will need to use data recovery tools or other analysis tools like binwalk to extract the concatenated binary blob. Essentially the same tools that are used to recover deleted files should be able to extract your documents again. Without any filename of course. I recommend renaming the file to a disk image (.img) and either mounting it from within the operating system as a virtual harddisk (don't worry that it has no file system - it should show up as an unformatted drive) or directly using a data recovery tool or analysis tool which can read binary files (binwalk, for instance, can do that directly, but may not find all types of files as it's mainly for unpacking firmware images that may be assembled in the same or a similar way to how your files ended up).
I've got an image that I write onto a bootable USB that I need to tweak. I've managed to mount the stick as /dev/loopX including allowing for the partition start offset, and I can read files from it. However writing back 'seems to work' (no errors reported) but after writing the resulting tweaked image to a USB drive, I can no longer read the tweaked files correctly.
The file that fails is large and also a compressed tarfile.
Is writing back in this manner simply a 'no-no' or is there some way to make this work?
If possible, I don't want to reformat the partition and rewrite from scratch because that will (I assume) change the UUID and then I need to go worry about the boot partition etc.
I believe I have the answer. When using losetup to create a writeable virtual device from the partition on your USB drive, you must specify the --sizelimit parameter as well as the offset parameter. If you don't then the resulting writes can go past the last defined sector on the partition (presumably requires your USB drive to have extra space). Linux reports no errors until later when you try to read. The key hints/evidence for this are that when reads (or (re)written data) fail, dmesg shows read errors attempting to read past the end of the drive. fsck tools such as dosfsck also indicate that the drive claims to be larger than it is.
I'm using rsync to perform synchronisation between two machines on a network, so I have rsync's --compress setting enabled, however I have various file-types that I'm excluded that I know are already compressed such .jpg, .mp4 etc, using the --skip-compress option.
However, I have a large number of files with no extension that I know to have poor compression (due to encryption), as part of OS X's sparsebundle disk image format (where each "block" of the image is its own file with no file extension.
Anyway, I don't have many other files that should conflict, as other files that I have with no extension should be either excluded already or are quite small (so not really worth compressing).
However, I'm at a loss as to how I should add no extension files to rsync's --skip-compress list?
Going up one level: How much time are you saving with --skip-compress?
On a 0.5 megabyte/s network link, a 21 megabyte mp3 file with suffices mp3, txt and none I tried
--skip-compress="[]/gz/foo" and --skip-compress="gz//foo". I could not find a difference in the speed over 5 tries.