Hi guys.
Well according to the research I had, and MP3 file structure is as follows:
AAAAAAAA AAABBCCD EEEEFFGH IIJJKLMM which is refered to as frames, and each. Each letter is one bit.
I've seen samples demonstrating how to get data from this but what I want is to get/access letter "H" in the above frames. Anyone knows how I can go about doing that? Here are the samples of getting information of the file. VbCity, Codeproject, Info about MP3 structure.
Knowing more fully what you are trying to acccomplish would be useful.
Do tell what the goals are. There are many fine libraries out there and some are .NET with source. http://professionaltag.sourceforge.net/
If you plan to write your own app (wrapper) but don't want to write your own tag code you can use either Perry's IDs Tag Library (which I have used) or this one which I have not tried.
Thanks guys. @rubberman & @rproffitt, the idea is to write some sort of key on this field as it is free. Now I want to be able to write and read the key from this field. Also I didn't get exactly how the data is written to these. The data that I'm refering to is "Artist, Album, Genre,etc" as to how is it written on these frames.
@Jim thanks I've checked the first link and downloaded the ID3 v4 but I had problems when trying to execute the sample app I did following the guide provided on that page so I will download the other Vs and see if they will still produce the same problem or not.
So how can I read an mp3 file and get the data as frames just as the structure of the mp3 and also how to access each bit within the frames? Thank you.
I think everyone asked what you are trying to do. You have a reason to write some information for this MP3 and have decided how to do that but, here's the question again.
Why are you wanting to do this to MP3 files?
For example you may be trying to mark them as played or stamp them as yours or other. Tell what the reasons are and maybe that's already been solved without corrupting someone's MP3 collection. Which would get folk very mad at you!
Ok basically the key will be a locater of the header. What I want to do is to first corrupt the mp3 by mixing its binary and then have this key which will tell the application that will be opening this file to how to begin reading it and where is header of the file is located and how to access it. But it may not be the header that I will mix but what I want to do is to make this file not supported players because it will be corrupted but I want to write some sort of a key there which will tell how the file could be correctly played.
I think you now have a picture of what I'm attempting to do.
That sounds like you are trying to write one of those very bad apps that ransom folk for unlocking their files.
Asking for such help with creating ransomware is going to bring out some very negative replies.
-> Let me be clear here. It sounds like you are working on ransomware. You can guess how I feel about that.
Well it may sound as a bad application but I'm not developing a bad application. What I'm trying to do is to create my own format, this format will be used to all the computers/devices that are certified by us to prevent the media from being played by every player. The idea is to replace or should I say un-support the commercially available media players and only support my format so instead of creating my own music/media format from scrath will take time to complete and also not to mention the research that will be conducted so the easy way is to take the already clear enough, in good quality formats and corrupt the media or mix around the bytes and have a key which will tell my media player how to play the file.
This will also ensures that my media files are not being converted from my secured format to the currently available formats because if thats happens then the media/files will be played by any media player of which is what I'm trying to avoid here. I'm not making any bad application. As a developer I'm sure you have also developed good application which if you tell or ask someone about a certain activity as to how to perform it, they immediatly thinks it a bad application. Making an example. A keylogger application one might use it in a bad way and another might use it in a good way as a system monitoring system where he monitors employees, child activities they do within his computer. So I don't want people to think that I'm behind anything bad and since you have started I'm sure many people now will think that I'm behind something bad of which I'm not.
The reason why I didn't want to mention the main idea was because the idea might be stolen, but the application is of good use not bad use.
Just what the world needs. Another audio standard. Good luck with your works.
And now this has took a wrong side with just a simple question of how can I read the desired bit(tag) and the entire thread has missed the core question with the negetivity. Well I wont be turned down by such negetive comments because I want to do this and maybe if all went well you will be using the very same tool as well, but who knows what the future has instore for us? Lets not focus on the negativity if you know the solution you can help by stating it or point to the write documentaion, for once be positive about other peoples ideas because you don't know what drive them. Thank you.
Mr.M All the libraries to work tags are out there. If you want to alter them, go right ahead. One of the things I notice in this forum is that folk don't write code for anyone. They give general direction and will drill down and help fix a few lines of errant code.
I see great advice above and maybe you are looking for someone to code something up for you. Maybe that's why you are getting such slow responses.
So how to edit fields, is a done deal. Use existing libraries. Want to change how they work, change the code.
Beside looking for example code I also want to understand how it is read it can be theoritical it not a problem as I will be working with different formats I need to understand each format as to how its work, structured, and so on. Well what I wanted was to know how to get the frame headers bits similar to the above, the sample provided above turns out to be of the tags but not the frame header where as I want to know about the frame header bits. Take a look at this refer to section 4.28, you will need to also use this and on this refer to frame header bit (H) which the whole question is about.
To me the question is clear and you have your documentation on MP3. Now you have libraries so what's missing here?
Even the H bit is documented. http://www.mp3-tech.org/programmer/frame_header.html
"Private bit. This one is only informative."
At this point I think all your questions have answers.
Except possibly the question "given a choice between a format (mp3) supported by every media player on the planet, and your hypothetical media player which will be the only one to play your special format, why would anyone want to use either your files or your player?"
@Jim, well the format part is just a building block or should I say a puzzel piece, the whole project is not just about introducing/making new format, but the format is to control so that desired people will use the protected format.
This project involves lots of other micro-projects which all when done will form one solution. So either you like it or not, but to play that media that is with this format you will have to have the system that recorgnize it or else you won't open/play it. Just to clear out of my
hypothetical media
While I think you've been a little short on detail, why not put the MP3 directly into your app's resources?
If you need to know how, here's the google on that. https://www.google.com/search?q=embed+mp3+in+my+vb.net+app
This way, it's not ready to play anywhere but your app.
But someone might crack that up and get the MP3 file. The Idea is that the file can be distributed with special CD/DVDs which we will recommend to our customers, and they can insert the removable media that contains the files to the media player, if the file is MP3 then they will just play it, but I don't want that, because before a file is being played there other other things that needs to be verified with that each file, so the idea I had was to mix some portion of MP3 file header and when the file has been checked and passed then it can be allowed to be played by telling the requesting media player how to play it.
Making an example, the header is originally like this: AAAAAAAA AAABBCCD EEEEFFGH IIJJKLMM
and what I want is to lets say I corrupt the file by mixing like this :AAABBCCD AAAAAAAA EEEEFFGH IIJJKLMN
Now the file is like that and most players will fail to play because its mixed around/corrupted so now on "H" I will write digit number "2" which means H will be having a digit number 2 which tells that the first header is frame is located on position 2 and skip one position get the second position as a frame, and when the first frame has been located then minuse 1 from the H which tells where the second fram is located.
The formular is as follows (get the first frame location, H-1 = second frame location) which is H (H-1) =1 which is a temp and also the real Key which is 2 like this 2*(2-1 =1 temp) = 2 real key, temp is returned by the math rule which says you start with brackets and work the rest after that.
You need to revisit this. Ready?
"Any code written by man can be broken by man."
If you want this to be airtight, you lost the battle before it started. There's plenty of source about MP3 so there's nothing lacking out there. But you have decided to take a long hard path so get to it before your app's window of opportunity closes.
So use rproffitt's suggestion but encrypt the embedded mp3. Or distribute the encrypted mp3s as separate files and embed the decryption key in your application.
The Idea is that the file can be distributed with special CD/DVDs which we will recommend to our customers, and they can insert the removable media that contains the files to the media player, if the file is MP3 then they will just play it, but I don't want that, because before a file is being played there other other things that needs to be verified with that each file, so the idea I had was to mix some portion of MP3 file header and when the file has been checked and passed then it can be allowed to be played by telling the requesting media player how to play it.
Sounds like some "Mission Impossible" "this tape will safe destruct" kind of thing from the Cold War. What problem are you trying to solve? What do you lose if someone unauthorized manages to play this file? Is this an anti-piracy thing where you are afraid I'll buy a Metallica mp3, then upload it to whatever today's version of Napster is and everyone downloads it for free? As far as the "checked and passed" part, is that a hash code type of thing? What are you "verifying"? I assume that this method is proprietary and thus not shared with the world. So I download a file in .mrm (for Mr. M) format. This file is useless to me unless I download the player from mrmindustries.com, which is the only player on Earth that can decode .mrm files, correct? The encoding method is kept private/trademarked? If I'm a software designer, I am discouraged/forbidden to attempt to write software that can play .mrm files, and I am also discouraged/forbidden from creating an app that converts .mrm files to .mp3 files?
Clearly you are not trying to improve on the mp3 format because you're just starting with an .mp3 file and jumbling it. Are the users of this special player the general public buying songs that anyone can buy or is there some kind of sensitive information on these files that you need to make sure that only authorized people can listen to? You mention the word "customers". Who are your customers?
As far as someone stealing the idea, no one can steal it with you being so vague. The downside is no one can help you either because you're being so vague.
Thanks but the media protection I've an already finished system which will protect the file, its like a bag with files and the bag is locked, so I have that covered. Only want to write "2" to "H" and read it as well, thats all I'm looking for.
H is one bit. You can write 0 or 1 to the H bit, but you can't write 2. What's wrong with using those already-posted tag libraries to write and read the H bit again? All the tag systems look like they change and read bits, but the format remains .mp3, by design. You on the other hand are trying to make an .mp3 unplayable, so by definition you are no longer manipulating an .mp3 file into another .mp3 (just manipulating the H bit does not make it unplayable, by definition). Once you "corrupt" the .mp3 file, you need to either provide a way to "uncorrupt" it so I can play it on any player that plays .mp3, or you need to provide the one player that can play this new .mrm format.
If the former, just encrypt and decrypt the darn file with the existing methods and provide the key for access control.
If the latter, you have to write your own .mp3 player, then add the extra steps of playing the actual sound data blocks in the right order. Once you actually write the real .mp3 player, changing the H bits, extracting the actual sound data and playing those data blocks in the un-mixed-up order will be child's play. The nice thing is that since you are creating your own format, which no one else can use, you can stick whatever you want in front of the normal .mp3 file along with extra encoding rules, make the H bit two bits or three bits or not use it at all, etc.
Your question now becomes either "How to I encrypt a file?" or "How do I write my own mp3 player?". "How do I change the H bit?" is a subset of "How do I write my own mp3 player?"
And I don't understand why those tag libraries don't answer the "How do I change the H bit?" question. Have you tried them?
OK. Simple question, simple answer. Do a binary read of the file, modify the bit/byte, then do a binary write of the file. Just make sure you change the extension from mp3 to something else because once you make the file decodable/unplayable it is no longer an mp3 file.
Thanks everyone. @Jim, I tried that out and it only returned "ID3" with some special charector after "3". But I've found this and looked it close.
@Null
you can stick whatever you want in front of the normal .mp3 file along with extra encoding rules
I like this. But now since the H is one bit either 0 or 1 and can't write 2/3/4/5... on it, I think I have to try something else like hidding a file on it which will contain info of the file like the rule of how this file can be corrected and played. Also I yesterday I tried to answer your questions but electricity in this play went off and the router was powerless, but here is the yesterday post I wrote yesterday to answer your questions, I now copied and pasted i below:
'@AssertNull, If I say what exactly I'm doing I know for sure I will get lots of nagetive comments as I've seen
lots of other people who had tried this were also discouraged by nagetive comments. Well I personally don't really
believe in Imposible because even it word is dicy as it also written "I'm possible". Let me provide you answers based on your questions.
1) The problem is the same as any Digital media problem of unAuthorized copying of files.
2) Personally I don't loose anything but those who are stackholders within digital media are loosing a lot.
3) Yes, its an anti-piracy thing.
4) Well for this part I will not reveale it since I've already revealed one part which was surppose to be private for the security of the system.
5) Also this links to No4 so this is also private. If I say this then everyone will know number 4.
6) Well there are other partners we have, so it is 40% chance that you will download this, you will use this without even knowing or being aware of it.
7) Well as I've said we have other partners we are working with so not everyone will be able to develop applications that will work with this but only
those we certify, meaning no individual will be provided with APIs or tools/documentations of how to play these file, but only organizations that we certify.
This is more like a Banking systems which is not available to the public to reduce risk of people developing their own systems that will interface/use their systems.
Never mind that now this seems publicly available due to the lick of the NCR document which showed the world how to do what was meant to be private.
But the less people know how to work with it the better chance it last a bit longer while we also investigate in even supper advanced ways of doing this.
8) As an individual developer who's just want to try it out then you are forbidden to do so unless you provide all the requirement or meet our requirements of which
you must be an organization that can be verified, and also some other details required. But only those organizations are certified by us will be able to do so.
9) Its Public, but the player will be freely available but not to an individual, a person can not buy/download it, but it will be preInstalled by our partners.
10) Our customers are Digital Medial stackholders(recording labels, Studios, Software development companies this also include game developers, the public as a whole).
Well I think the only part that I was vague with was that "What I'm behind, why, and details which as much as it is related to the question by was not a part of a question
as it was not on a question and this should have been ignored as it doesn't relate to the core/main question of simply how to write to "H" bit of a MP3 frame header and also how to ready this bit only.
But now people wan't to know even the info that is not on the question.
Question: How to read/locate bit "H"?
Answer: The bit can be read like this.
The bit can be written like this.
As I've said the examples that I've seen only show how to access "tags" not "Bits".
What I was vague with is the private information, the question is clear enough of what was asked but then what can I do, now that I've provided even what the project is about
and that now everyone sees that I'm not doing any ransomeware or bad application/system lets hope I will no longer get negative comments/suspected of bad/unlawful things.
Well I haven't failed, because most of the parts are now done and ready only need to get a solution to this problem thats all. Also to add, We chose MP3 because its best used and everyone preffers it and use it
so that means it is a good quality format/codec so simply corrupting a file will cause Media players to be unable to play the file so inorder to be able to play it, a translater is required which is what I'm trying to do here.
1) Corrupt the file.
2) Store a correction Key to "H"
3) distribute the file.
a) User try to open this file, if he doesn't have this translator then the file will be unrecorgnized and unsurppoted to his/her device.
b) Translator translate the file.
c) Media player plays it. But the catch is that the media play must also recorgnize the file.
Dealing with unAuthorized copying is not part of this and has already been covered and done with it, so Please people don't bring any question related to it of how we dealt with that and other info that might be private.
Hope everything is clear,straight, and every question is answered, but if not you can ask as long as its doesn't attempt to reveal private info.'
Here is some sample code to read the entire contents of a file into a byte array, modify one byte, then write the file back out. This code replaces one byte with another. I'll leave it up to you to determine (from your bit number), which bit of which byte is to be modified. It's pretty simple math.
Dim bytes = My.Computer.FileSystem.ReadAllBytes(TESTFILE)
bytes(4) = Asc("\")
My.Computer.FileSystem.WriteAllBytes(TESTFILE, bytes, False)Here's some code that takes a string "Hello World", changes the 13th bit from 1 to 0 (changing 'e' to 'a'), saves to file, then opens the file back up and changes the 13th bit back to 1 and saves ("Hello World" again), then reads the file again to double-check. Change the hBitLocation variable from 13 to whatever you whichever bit you want to change (i.e. change it bit 14 and you get "Hcllo World").
#include <iostream>
#include <fstream>
#include <cstdlib>
#include <cassert>
#include <cstring>
using namespace std;
void SetBit(unsigned char& byte, unsigned char bitValue, unsigned char bitLoc)
{
assert(byte <= 255);
assert(bitValue < 2);
assert(bitLoc < 8);
unsigned char ormask = (1 << (7 - bitLoc));
unsigned char andmask = 255 - ormask;
if(bitValue)
byte |= ormask;
else
byte &= andmask;
}
unsigned char GetBit(unsigned char byte, unsigned char bitLoc)
{
assert(byte <= 255);
assert(bitLoc < 8);
unsigned char mask = (1 << (7 - bitLoc));
return ((byte & mask) >> (7 - bitLoc));
}
int main(int argc, char* argv[])
{
unsigned int hBitLocation = 13;
unsigned int byteNumber = hBitLocation / 8;
unsigned int bitNumber = hBitLocation % 8;
const char* greeting = "Hello World";
unsigned char bytes[12];
strcpy((char*) bytes, greeting);
// Hello World
cout << (char*) bytes << ": Bit " << hBitLocation << " is " << (int) GetBit(bytes[byteNumber], bitNumber) << "\n"; // "Hello World"
// Change bit 13 to 0. "Hallo World"
SetBit(bytes[byteNumber], 0, bitNumber); // Change to "Hallo World"
cout << (char*) bytes << ": Bit " << hBitLocation << " is " << (int) GetBit(bytes[byteNumber], bitNumber) << "\n"; // "Hallo World"
// save wrong spelling. "Hallo World"
ofstream file1("file.mrm", ios::out | ios::binary);
file1.write((char*) bytes, 12);
file1.close();
// change bit 13 back to 1 to correct spelling
fstream file2("file.mrm", ios::in | ios::out | ios::binary);
file2.seekg(byteNumber, file2.beg);
unsigned char byte = file2.peek();
SetBit(byte, 1, bitNumber);
file2.write((char*) &byte, 1);
file2.close();
// now open up the file again to test to make sure it's spelled right
memset(bytes, 0, 12); // blank out memory
ifstream file3("file.mrm", ios::in | ios::binary);
file3.read((char*) bytes, 12);
file3.close();
cout << (char*) bytes << ": Bit " << hBitLocation << " is " << (int) GetBit(bytes[byteNumber], bitNumber) << "\n"; // "Hello World"
return 0;
}Useful except the OP has this thread tagged with vb.net. Bit operations on bytes can be done easily with
Function SetBit(ByVal byteval As Byte, ByVal bitnum As Byte) As Byte
Return byteval Or (1 << (7 - bitnum))
End Function
Function ClrBit(ByVal byteval As Byte, ByVal bitnum As Byte) As Byte
Return byteval And (255 Xor (1 << (7 - bitnum)))
End Function
Function FlipBit(ByVal byteval As Byte, ByVal bitnum As Byte) As Byte
Return byteval Xor (1 << (7 - bitnum))
End FunctionNote that these functions number the bits left to right (MSB to LSB) zero-relative.
thread tagged with vb.net
Missed that part. Thanks. I'm looking at the tags below the reply box, which has C++ and a whole bunch of others too: "array", "assembly", "c", "c#", "c++", "java", "python", "vb.net", "visual-basic-6". What do those tags refer to? Obviously not the tags for this thread. Whoops.
Anyway, there you go Mr. M. That's how you change a bit in a file using C++, which is not what you need, so look at Reverend Jim's post.
Last comment from me since I have nothing to offer regarding VB.NET. Your project got me thinking and investigating and experimenting, etc. I'll take your word that there's nothing "bad" about what you are doing, so...
You've been trying to mess around with the H bit and you can do that, but as far as I can tell, that H bit is skipped by players, so doing anything to it won't "corrupt" anything. However, look at the D bit instead of the H bit. The D bit specifies whether there is a 16 bit CRC following following the M bits. See if that D bit is 1. If it is, the CRC bits alreeady exist in the file. If not, set that D bit to 1 and then insert 16 bits between the M bits and the actual music bits. For the intentionally "corrupted" version of the file, set those CRC bits to anything but the legitimate calculated CRC. Any mp3 player actually relying on the CRC will flag that as corrupt and unplayable, though some might perhaps not bother and play anyway. Best thing is if the MP3 player does what it's supposed to and doesn't play the sound segments with the bad CRC on them, which will be all of them, intentionally. Worst that can happen is that you have 16 extra bits per frame to write whatever you need to write in order to make the MP3 unplayable if you want and then also fix it. When everything's the way it's supposed to be, either delete the 16 CRC bits and make the D bit 0 or keep it as 1 and calculate the good CRC and stick it in those 16 bits. Gives you more bits to play with and, by design, the MP3 format tells you exactly where and how to "corrupt" the mp3 file.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.