Looking to get artist, title, album from ID3 information on a remote audio file. I don't want to download the entire file, so I only download the first 500 or so bytes. I can see the ID3 information when viewing the body, unfortunately when I call Mutagen https://code.google.com/p/mutagen/ pointing to the small file, an error is thrown
EOFError: Requested 0x1a501 of 0x1ce9 (file.mp3)
Is there any way to fix this file? Corrupted?
You're missing data. You might need more than 500 bytes, since the error indicates it's trying to load offset 107,777. I'm not familiar with Mutagen myself, but you might need to modify it to accept "broken" files.
Also, keep in mind that ID3v1 is stored at the end of the file, not the beginning. If you're dealing with ID3v2 exclusively, this isn't a problem.
Related
Sorry for making such an unclear title
I have a disk image disk.raw from which I carved deleted files using Sleuth Kit and its command blkls disk.raw 1-8000 > carved which put into a file the data in the unallocated blocks from 1 to 8000 (where I know my deleted files are)
So my output is a file containing some data and many empty spaces in between. For example, if I open it on a notepad, I get texts like these :
1 4 µ½;ÓóÆJv4éA°¿S*îÔy÷è„¡d:ÄÕԈȤÒX2ÛK]8øâ†+[ÛÖ7jiº;Îàdƒ”ÜRÒ€
¥¾‘…λ5y)‹F¹ž8rÀÉø±9ŸÎ:ÿf¤$cªW›
jȉ…j,ܬ3®°d¥²¥®:Þ FhãŽß[ÔÀZ
÷·Îâ#§B¢† Uƒ†=qÁ[е#Sy(JØš#œKÊÏ9êþáð0•›nÊÑ=q¡ŽšOk'ë#ëÚšÚjN1V&l?Hù´m,0㼕(nôTúèªÎb4z
„áñP$¼YèÐ%É‚YSÄÔΔú%ió΃P¥ð"÷…ž8«¾oÀE‚f¤X§üS(‘Àº.8H§÷ëü1¥ãùBÁ
ÏÉε”˜Ê<wªf”œàºš¯+kô¨§
÷*ÎÛMøÈ”Âqú2>XME[9¿
[æÀ‹dJ¹—×™
#¦e³ž‹
&ýãY
™qA›¥ì„5šI‰h{?–hZ%"?mÓ{ƒÌ‡5mf
R‹sàì‰;½˜\E€Îñ$‡jYÀK%ØnDwí[=û Ú‘;1„LQP!ðè.¦(w
‘ªb,†ä‚ž8®©8¢BMMã×›Œx
£®‘ÚFëÖбgi·ÖŠ.O&ÂëR¹5–{íy˜÷æ¡žÜç¦^ñbj˜1Úî5G)©Äš¸#¡
? qâ1q[µ£É>½¥f–#žÞPžR›#T3lÂ.DcSÚ˥ѹ‹e¬·!$ù“àYž{¨Ü˜ÉbJ…8¬‘#"b 3Ø„¤Í
qµ~#©Á42û,èLE²‰Iv+Áƒ™MšÅÄ
$Bn×ÖXya1£²ŒJçj-Õ7 :AÚ0è#eP#sef}#NÈè?¸¯ãß8µ#Q?ÒY͆ۡ)†ë3F›Œ[ŽF®8©!PóÚª]p [íˆyÊn;ãÕ§rBvÏŸ`‚ȨŠöMë÷S¸50¦è€\¾i'7ÒÚTT•vˆ›™¸ë‹ƒÞS>ðºjû&]WÆ–˜ÚÔG•5ÚÑÎ¥Vñ`;´0æ6\wuo«íîÕµ¬t–‚Âþ‘)ü¨Òíi¼_¡•o_iùab›,âezkM#Þæ]–h6Š¨+S$"4”4^ÞóD*í£0Ìmk¼#G•¨pG‡Ï{∉ŒB™ƒ)1Y¸E1<1¼
S’5éà‚z[A¬TD‰·Ý¾é m2ËTÍÌšÛrvF€Â«j¤ô?ÿþ¢Zh4œ6<劕n´öñ>ï9Ì}
I know that those bunch of data represents a compressed file. Is there a way for me to decode these and read the files inside ? Is there a tool that does that given this previous input ?
I'm really new to this and have basic knowledge :)
Thank you kindly in advance,
Sometimes carved files lose their headers format, repairing it might lead to the file being accessible again. As mentioned by Mark Setchell using a hex editor is better than a notepad. Make sure also to look for the correct header and save the file again with the correct format. Hopefully this is helpful.
I need to get any information about where the file is physically located on the NTFS disk. Absolute offset, cluster ID..anything.
I need to scan the disk twice, once to get allocated files and one more time I'll need to open partition directly in RAW mode and try to find the rest of data (from deleted files). I need a way to understand that the data I found is the same as the data I've already handled previously as file. As I'm scanning disk in raw mode, the offset of the data I found can be somehow converted to the offset of the file (having information about disk geometry). Is there any way to do this? Other solutions are accepted as well.
Now I'm playing with FSCTL_GET_NTFS_FILE_RECORD, but can't make it work at the moment and I'm not really sure it will help.
UPDATE
I found the following function
http://msdn.microsoft.com/en-us/library/windows/desktop/aa364952(v=vs.85).aspx
It returns structure that contains nFileIndexHigh and nFileIndexLow variables.
Documentation says
The identifier that is stored in the nFileIndexHigh and nFileIndexLow members is called the file ID. Support for file IDs is file system-specific. File IDs are not guaranteed to be unique over time, because file systems are free to reuse them. In some cases, the file ID for a file can change over time.
I don't really understand what is this. I can't connect it to the physical location of file. Is it possible later to extract this file ID from MFT?
UPDATE
Found this:
This identifier and the volume serial number uniquely identify a file. This number can change when the system is restarted or when the file is opened.
This doesn't satisfy my requirements, because I'm going to open the file and the fact that ID might change doesn't make me happy.
Any ideas?
Use the Defragmentation IOCTLs. For example, FSCTL_GET_RETRIEVAL_POINTERS will tell you the extents which contain file data.
Reference: http://id3.org/id3v2.3.0#ID3v2_overview
It seems as though ID3 Tags just don't do all the things I want it to do. I was thinking I could write information to the comments and use the comments field as my storage of a better data structure, but that's pretty hacky. I wanted to find out, in a general sense, what directions I have available to me. Can I write something like an ID3 tag to a file or is it built into what an MP3 is?
If no, does this mean other than storing a mapping to files outside of the file I have to live inside the ID3 fields?
If yes, can I do this to any file? Is there something special about MP3s that allows you to write arbitrary meta data or could I do this with WAV files as well.
I know that for some people this is probably the basics of how files work, so I apologize if it's obvious.
Thanks!
UPDATE: It seems like using npm groove I an write any metadata field I want to the file. Does this mean that ID3 is just a standard of metadata fields and anyone can write any [key, value] metadata information to any file? Because that's what it seems like, and that's awesome.
Basically, you can write any data AROUND your files. This kind of metadata around MP3 music data is called ID3. ID3 is available for other formats too.
The main problem that you will run into: You have to be sure that your devices reading such files are capable to interpret your metadata. Simple example: If you would write an ID3-Tag around a JPG-File, you can be (almost) sure, that no 3rd party program or device will read this metadata. Most of the graphics program will not even read the JPG-picture-part anymore, because no one would expect an ID3-Tag around an JPG file. (This kind of metadata would be added in a EXIF-Tag).
As long as you add an ID3-Tag to MP3 music files, you can add whatever you want. In addition to all the existing standard tags you can even add your own private frames with your very specific informations. If like to add the 'eye color of the lead singer' in your own specifc ID3 tag, feel free to do that.
Greetings all,
I am currently a rising Sophomore (CS major), and this summer, I'm trying to teach myself C++ (my school codes mainly in Java).
I have read many guides on C++ and gotten to the part with ofstream, saving and editing .txt files.
Now, I am interested in simply importing an image (jpeg, bitmap, not really important) and renaming the aforementioned image.
I have googled, asked around but to no avail.
Is this process possible without the download of external libraries (I dled CImg)?
Any hints or tips on how to expedite my goal would be much appreciated
Renaming an image is typically about the same as renaming any other file.
If you want to do more than that, you can also change the data in the Title field of the IPTC metadata. This does not require JPEG decoding, or anything like that -- you need to know the file format well enough to be able to find the IPTC metadata, and study the IPTC format well enough to find the Title field, but that's about all. Exactly how you'll get to the IPTC metadata will vary -- navigating a TIFF (for one example) takes a fair amount of code all by itself.
When you say "renaming the aforementioned image," do you mean changing metadata in the image file, or just changing the file name? If you are referring to metadata, then you need to either understand the file format or use a library that understands the file format. It's going to be different for each type of image file. If you basically just want to copy a file, you can either stream the contents from one file stream to another, or use a file system API.
std::ifstream infs("input.txt", std::ios::binary);
std::ofstream outfs("output.txt", std::ios::binary);
outfs << insfs.rdbuf();
An example of a file system API is CopyFile on Win32.
It's possible without libraries - you just need the image specs and 'C', the question is why?
Targa or bmp are probably the easiest, it's just a header and the image data as a binary block of values.
Gif, jpeg and png are more complex - the data is compressed
I've seen a lot of games use something similar to a .DAT file or a specific file type that the game has for itself. I'm just beginning with C++ and DirectX and I was interested in keeping my information in something similar to a .DAT.
My initial conception was that it would hold information on the files you wanted to store within the .DAT file. Something similar to a .RAR file. Unfortunately, my googleing skills did not help me in finding the answers.
Right now I'm simply loading textures and sound files from a folder called Data.
EDIT: While I understand that .DAT is short for data, and I've found that a .DAT file generally contains any assortment of information, I'm still unsure about how to go about doing something as packing images and sound files into any type of file and being able to read them.
I'm not sure about using fstreams to achieve my task, however I will look into streams related to storing data and how to properly read from that data. Meanwhile if anyone has another answer to offer based on this new information, it would be appreciated.
EDIT: Thanks to the answers, I stumbled across a similar question on stackoverflow and felt I'd share it here. Combining resources into a single binary file
I don't think there is really such thing as .dat file format. It's short for "data," and different applications just put in some proprietary stuff in it and call it ".dat." You can read up on fstream classes to do file IO in C++. See Input/Output with files.
What you then do is make up your own file format. For example, first 4 byte is int that indicates the number of blocks in the .dat and for each block, you have 4 byte indicating the length of each block, 4 byte indicating the type of the block, the variable length data itself .. something like that.
DAT obviously stands for data, and there is no real or de facto standard on what that extension actually refers to. Your decisions on the best file formats should be based on technical considerations, not pointless attempts at security through obscurity.
Professional games use a technique where they put all the needed resources (models, textures, sounds, ai, config, etc) zipped/packed into a single file thus making it faster to manage, harder to change (some even make use of a virtual filing system from what's inside the data file). Now, for what's inside the file is different depending on the needs of the game and the data structures that you use.
If you're just starting into gamedev, i recommend you stick with keeping all you assets separate and don't bother too much about packing them into a single file.
Now if you really want to start using a packed format here's a good pointer:
Creating a PAK File Format
Here's a link which claims that .dat is a movie format, 'DAT' being short for Digital Audio Tape.
I'm not sure I believe the link, but I do remember something about a Microsoft supported format called DAT, from long ago, when I used an earlier version of Windows.
It makes more sense as a logical extension for a DATA file of some kind.
.dat, as others have said, is literally just a data file. In reality, the file extension means nothing other than association with a program. For example, I could make a word processor that saves all the documents with the .mp3 file extension. These files wouldn't be playable in any media software, but the software might try. File extensions are used to help programs know what types of files they can and cannot open--however those rules don't have to be followed.
Anyway, you can dump any sort of information to a file. Programmers/software writers will often choose .dat as the extension of that file because it has become the standard to signify 'this file just holds a ton of data' and that the data doesn't necessarily hold any standardized headers, footers, or formatting.
A dat file could really contain anything. It might be as simple as a zip archive with the extension changed, or it could be a completely custom file type. If you're just starting out, you probably don't want to write your own file format, although doing so can be fun and educational. If you want to encapsulate your data files into some kind of container, you should probably go with a zip, paq, or maybe tar.gz.