Done. Results are that the differences between a wav and its mp3 are about the same as the differences between an ogg and the mp3 it was made from. The magnitudes are similar, as are the spectrum views except for frequencies above ~15kHz. My guess for this is that the mp3 lost all of the high frequencies to start with and the ogg didn't put any in at all. I also compared the ogg to the original wave. The magnitude is a little larger than the wave-mp3 diff, but not much. The spectrum of the ogg-wav diff looks almost exactlly the same as the mp3-wav diff. Also, I used variable bitrates for both the ogg and mp3, and the ogg actually averaged 111 kbps, and the mp3 was 123 kbps. If you use a higher bitrate ogg (say 180 kbps) the loss is notacibly smaller than the initial mp3 loss.
I can barely hear any difference between the ogg and the original wav file. With audio recorded off of the radio (instead of ripped from a cd) I could not hear any difference at all. As far as i know I am not deaf or anything, and I am testing this on THX certified speakers. SB live! soundcard too.
Conclusion: Transcoding is not a big deal at higher bitrates. Total loss going from wav-mp3-ogg is about the same, or less than the loss with an FM radio broadcast. Lower bitrates probably matter.
Untill the filter writter sees this, and updates the filter to extract the password/key. If the RIAA has the tools to force this filter into p2p apps, they will have more than enough tools to win this arms race, especially since they only have to reduce p2p sharing below critical mass to kill it.
Nope. For this to work someone would have to post the wrapper online somewhere, or information on how to make it. The filter writer will see this, and update the p2p app to detect it. The p2p app will refuse to run wrapped.
Besides, if you can create such a side channel for info, forget the encryption key, send the file itself! Much simpler.
You basically have a p2p app without the filter. Which means that whatever method was used to put the filter in the original app will now be forced into your side channel , which means even if you were still sending the key, the app now has it and stops the file transfer.
Sending the key outside the p2p app is not the answer. Besides, if it is outside the app, how do you know the IP address to send the key too? sniffing network traffic? And what is to stop the p2p app from doing the same thing? And seeing the key? Square one. It is an endless arms race, and one that I am sure that the filter writter would win, because for p2p to work, it must keep critical mass of sharers, most of which will not be able to find and update their side of the arms race fast enough to keep ahead.
Of course, p2p programs must be changed to support any encryption - and they must stay changed.
Why not just change them to not bother running the filter program? Or feed it data from/dev/urandom instead of the song? The p2p client and the filter must fully cooperate for this to work in the first place. I took that fact as a given. If you can modify the p2p client after the filter is added, then encryption, or zipping, or byte swapping is pointless, just disable the filter.
No, I am aware of asymmetrical encryption schemes. What I think you are missing is the fact that the p2p client(s) on both sides of the communication are now untrusted intermediaries. They contain the filtering program, and supposedly see all communications between them.
Person A encrypts a song and posts it for sharing. If person A's p2p client can decrypt the song, it will refuse to share it. Person B wants to download the song from person A. Person B needs the key that decrypts the song. If his p2p client can decrypt the song it won't download it.
The trick is to somehow send the decryption key through both p2p clients without either of them knowing what the key is, and still have person B know what it is. This would not be so hard except that the filter program writer is also looking, and if person B can get the decryption key, so can the filter writer. And if he can figure out how to tell the filter program where the key is, the file does not get sent. It does not matter if the decryption key is the encryption key or not, or even if it is just a 'play it backwards' hint.
Sendiong the key outside the p2p client moots the issue, just send the song instead!
Someone else found way to do this but even this is not foolproof (see the reply about blocking passworded zip files)
Not bad. Basically you encrypt the key using english, something the end user can decrypt, but the filter program can't. Even when the filter writer knows how it is encrypted. Nice.
Two points left, Can the typical p2p user do this well enough that there will still be enough people sharing these files to make using p2p worth the time? (chicken and egg problem, can you still get critical mass?) And what happens when the RIAA gets a hold of your IP address, and downloads one of these files from you. (like they have been?) Someone else pointed out that this would prove that you knew you were doing something wrong. Remember, in order for this filter to have started, some sort of draconian law needs to be passed in the first place.
The filename is avalible to the p2p client, which is also the filter. How long will it be before the filter writer figures this out and simply extracts the pw? This would be easier to impliment. There are only so many charactor combinations possible in a filename. Brute force try them all might work.
BTW, best possible way around it I have seen yet, people read stuff much easier than machines.
For sure. Partly because you can argue that game cracks have a valid fair use. This doesn't.
But if you can crack the sucker, why not just disable the stupid filter? Or send it to a fake database that always returns 'file is ok?' Why munge/encrypt the file at all? I never said that this was not defeatable, just that munging the file won't defeat it.
Remind me again how any of this communication happens. If it goes through the p2p client itself, the filter program is part of the client, and can snoop on the whole damn thing. If it is outside of the p2p client, how is the random p2p luser going to know about it? The trusted keys thing totally kills the scale that p2p systems need to be a real threat to the RIAA. It would become a geek thing only. Until someone gets caught, and the trust chain breaks. then not only can you be monitored, but the RIAA can prove that you were the initial sharer. ( a Bad Thing for sure)
But all you have to do is outpace the software for now.
For now? I don't get that part. For an internet-wide p2p (like the ones we have now) I see no way for the users of p2p to even keep up, let alone stay ahead. Without cracked/hacked clients of course, which moot the whole thing.
Of course you can have a private p2p system that would work. but you would have to have some way of communicating the 'secret' be it an encryption key, or the fact that the file is sent in reverse etc, in some way that the writer of this filtering program, and probably the filtering program cannot see. If you want to fileshare between your buddies/extended family, this can work, email it.
But can this system be extended to the internet population as a whole, as p2p is now?? No, because the p2p filter writter, and indeed the p2p filter program itself are part of the internet population. Post your keys to a public website? p2p filter writter grabs the keys and compiles them into the next 'update'. send them through p2p? the filter program itself grabs the key, decrypts the file. Kazza style p2p would be dead.
In your example, if both the server and the client(you) are typical p2p clients, your example falls flat immediatly. You sent the key through your client program, which has the filter program compiled in. It grabs the key. send it outside your client? the server you send it to is also a p2p program with the filter inside. It refuses to send the files to you, it analysed the files before encrypting in the first place. In short, munging the files like this is a temporary measure at best. The only way around this is cracked/hacked p2p clients, wich renders the munging moot.
Simple public-key encryption would not work. the public key must be available to the end downloader. Since the end downloader is a random person on the internet it would be available to the software, and the file is decrypted. All it would really accomplish is fingerprinting the initial sharer.
The same thing actually applies to any such transformation. The end-downloader needs to know how to play the file. There is no method that I can imagine to tell the downloader (random joe on the internet) without also telling the company who makes this softaware. And in the next update. . . dead.
No. Any such transformation, to work, must be publicly known. Any known scheme can be implimented in this software. An arms race on formats would ensue, but I don't see the p2p users keeping up. What you would see would be cracked versions, almost immediatly, just like you see with games. And locked-down hardware is required to stop that.
Solar power for generating electricty may not be the most efficient thing to do, but solar energy produces heat nicely. Solar stills are simple to do, and since you can store the product, cloudy days are not that big of a problem.
or you could burn the leftover mash (the stuff that did not ferment, and dry it of course) or run it through a methane digester, and run the still on the methane. Or scrap the alcohol alltogether and just run everything through the digester and sell methane!
My point is that there are plenty of sources of energy for this type of thing.
not all fusion generates neutrons, at least not in the same amounts. Unless these experiments are using heavy water, this is the reaction that is happening, note: no neutrons for the first stage ( p + p )
Ummm... charge more? If you really think that your work in creating the database was worth all that much, why the heck didn't you charge appropriately for it when you sold your work?
It is like charging licence fees for everyone who sits down on a chair that you made and sold, simply because you think that you should be compensated for the bennifit that they gained from your work. Stupid.
Said it before, will say it again, and probably get flamed for it again too.
Nobody has the right to profit from any activity. They only have the right to try. Trying to use the courts/government/force of any kind to make a particular activity profitable (or more profitable) is wrong.
For your particular case, The reason for copyright law is to promote the arts and sciences by increasing the incentive to create them. The idea of copyrighting databases would logically be to promote the creation of databases in the same way.
Unless you can show that society would be better off with more databases, or that we do not have enough databases, the only reason protect DB creators is to give them more money and power at the expense of others.
I think that there is already plenty of incentive to create DBs and no further incentive is needed.
This was lifted from another post months ago. Sorry, but I do not know who. I do agree with the ideas though.
Here's real campaign finance reform.
1. Only people who can vote (registered) for a candidate can donate money to that candidate. This would keep corporate money, out-of-district money, and out-of-state money out of the election.
2. Only people registered with a party could donate money to that party. Partys could not give money to candidates; they could only use the money to recruit new members, run issue ads, and finance their conventions (i.e. party business).
3. No limit on the amount of money a person could contribute. Only exception would be a percent of annual income, say, 10%. This would keep rich people from donating money in the names of poor people. (If Joe Sixpack donates a million dollars given to him by his boss, but earned only $18,000 last year, both could be prosecuted under election laws.)
4. No limit on spending by a candidate with donated money. Limit spending his own money to 10% of annual income.
5. Full and immediate disclosure of all sources of donations. This would let the voters see exactly who is trying to buy a candidate and let them decide accordingly.
So, if I were running for mayor of Anytown, USA, I could spend 10% of my annual income and all of the money donated to my campaign by citizens of Anytown who were registered voters. No money would be allowed from out-of-town corporations, etc..
If I were running for the U.S. Senate, I could accept money from any registered voter in my state.
Does money win elections? Ask President Steve Forbes.
The rules outlined above are not perfect, but wiser people than me could tweak them a bit.
I think that there are too many -ism's around here. They are all too vauge of terms to be of any real use in the debate. If you want to use these terms, please define more clearly what you mean by the term. Otherwise we all end up knocking the stuffing out of each others straw men.
BTW you did a fair job of this with your 'true capitalism == libertarian' statement, I am not knocking your post specifically.
Actually I would say 'don't confuse capitalism with corporatism' This law isn't about protectionism in the classic sense, (it says nothing about trade as far as I know) but it is all about corporations wanting to make more money for less work.
Side note, would the berne convention require other countries to honor this copyright??
Grumble... apparently the -q 10 option to oggenc overrides the -b 128 option. it actually was encoded at about 500kbps. I need to rerun everything to double check.
Replying to myself, I did it. In audacity the waveform looks like a flat line. Just a little bit thicker than silence. Playing it sounds something like wind going through trees. Lots of scratchy stuff.
I also comapred the original wave file to the mp3. The difference between the origonal wave and the mp3 is at least an order of magnitude (10x) larger than the difference between the mp3 and the transcoded ogg. For example, I amplified the original wave as far as you could without clipping before this test. I could have amplified the diff of the mp3 and ogg by 24.0 db without clipping.
commands used: lame --abr 128 file.wav oggenc -b 128 -q 10 file2.wav (full quality) file2.wav was exported from audacity using the imported mp3.
My conclusion, If you can't tell the difference between the original wav and the mp3, there is no way you will ever tell the difference between an mp3 and the ogg made from it, even using better speakers/amp etc, as long as the bitrates are the same. This was not an exhustive test, different songs/frequencies may be different YMMV, but I would not be afraid to transcode my stuff.
Ummmm, have you tried it? I know the theory, but I tried it just for fun. as long as the ogg was the same bitrate as the mp3, I could not tell the difference. Maby I'll do just that again, and then import both into audacity and do a diff to see what if any real difference there is.
Slashdot Mirror
I can barely hear any difference between the ogg and the original wav file. With audio recorded off of the radio (instead of ripped from a cd) I could not hear any difference at all. As far as i know I am not deaf or anything, and I am testing this on THX certified speakers. SB live! soundcard too.
Conclusion: Transcoding is not a big deal at higher bitrates. Total loss going from wav-mp3-ogg is about the same, or less than the loss with an FM radio broadcast. Lower bitrates probably matter.
Untill the filter writter sees this, and updates the filter to extract the password/key. If the RIAA has the tools to force this filter into p2p apps, they will have more than enough tools to win this arms race, especially since they only have to reduce p2p sharing below critical mass to kill it.
Besides, if you can create such a side channel for info, forget the encryption key, send the file itself! Much simpler.
You basically have a p2p app without the filter. Which means that whatever method was used to put the filter in the original app will now be forced into your side channel , which means even if you were still sending the key, the app now has it and stops the file transfer.
Sending the key outside the p2p app is not the answer. Besides, if it is outside the app, how do you know the IP address to send the key too? sniffing network traffic? And what is to stop the p2p app from doing the same thing? And seeing the key? Square one. It is an endless arms race, and one that I am sure that the filter writter would win, because for p2p to work, it must keep critical mass of sharers, most of which will not be able to find and update their side of the arms race fast enough to keep ahead.
Why not just change them to not bother running the filter program? Or feed it data from /dev/urandom instead of the song? The p2p client and the filter must fully cooperate for this to work in the first place. I took that fact as a given. If you can modify the p2p client after the filter is added, then encryption, or zipping, or byte swapping is pointless, just disable the filter.
Person A encrypts a song and posts it for sharing. If person A's p2p client can decrypt the song, it will refuse to share it. Person B wants to download the song from person A. Person B needs the key that decrypts the song. If his p2p client can decrypt the song it won't download it.
The trick is to somehow send the decryption key through both p2p clients without either of them knowing what the key is, and still have person B know what it is. This would not be so hard except that the filter program writer is also looking, and if person B can get the decryption key, so can the filter writer. And if he can figure out how to tell the filter program where the key is, the file does not get sent. It does not matter if the decryption key is the encryption key or not, or even if it is just a 'play it backwards' hint.
Sendiong the key outside the p2p client moots the issue, just send the song instead!
Someone else found way to do this but even this is not foolproof (see the reply about blocking passworded zip files)
Two points left, Can the typical p2p user do this well enough that there will still be enough people sharing these files to make using p2p worth the time? (chicken and egg problem, can you still get critical mass?) And what happens when the RIAA gets a hold of your IP address, and downloads one of these files from you. (like they have been?) Someone else pointed out that this would prove that you knew you were doing something wrong. Remember, in order for this filter to have started, some sort of draconian law needs to be passed in the first place.
BTW, best possible way around it I have seen yet, people read stuff much easier than machines.
But if you can crack the sucker, why not just disable the stupid filter? Or send it to a fake database that always returns 'file is ok?' Why munge/encrypt the file at all? I never said that this was not defeatable, just that munging the file won't defeat it.
But all you have to do is outpace the software for now.
For now? I don't get that part. For an internet-wide p2p (like the ones we have now) I see no way for the users of p2p to even keep up, let alone stay ahead. Without cracked/hacked clients of course, which moot the whole thing.
But can this system be extended to the internet population as a whole, as p2p is now?? No, because the p2p filter writter, and indeed the p2p filter program itself are part of the internet population. Post your keys to a public website? p2p filter writter grabs the keys and compiles them into the next 'update'. send them through p2p? the filter program itself grabs the key, decrypts the file. Kazza style p2p would be dead.
In your example, if both the server and the client(you) are typical p2p clients, your example falls flat immediatly. You sent the key through your client program, which has the filter program compiled in. It grabs the key. send it outside your client? the server you send it to is also a p2p program with the filter inside. It refuses to send the files to you, it analysed the files before encrypting in the first place. In short, munging the files like this is a temporary measure at best. The only way around this is cracked/hacked p2p clients, wich renders the munging moot.
Yup. Unplayable. Just what the person doing the download will think too. This won't work.
The same thing actually applies to any such transformation. The end-downloader needs to know how to play the file. There is no method that I can imagine to tell the downloader (random joe on the internet) without also telling the company who makes this softaware. And in the next update. . . dead.
No. Any such transformation, to work, must be publicly known. Any known scheme can be implimented in this software. An arms race on formats would ensue, but I don't see the p2p users keeping up. What you would see would be cracked versions, almost immediatly, just like you see with games. And locked-down hardware is required to stop that.
or you could burn the leftover mash (the stuff that did not ferment, and dry it of course) or run it through a methane digester, and run the still on the methane. Or scrap the alcohol alltogether and just run everything through the digester and sell methane!
My point is that there are plenty of sources of energy for this type of thing.
not all fusion generates neutrons, at least not in the same amounts. Unless these experiments are using heavy water, this is the reaction that is happening, note: no neutrons for the first stage ( p + p )
It is like charging licence fees for everyone who sits down on a chair that you made and sold, simply because you think that you should be compensated for the bennifit that they gained from your work. Stupid.
Nobody has the right to profit from any activity. They only have the right to try. Trying to use the courts/government/force of any kind to make a particular activity profitable (or more profitable) is wrong.
For your particular case, The reason for copyright law is to promote the arts and sciences by increasing the incentive to create them. The idea of copyrighting databases would logically be to promote the creation of databases in the same way.
Unless you can show that society would be better off with more databases, or that we do not have enough databases, the only reason protect DB creators is to give them more money and power at the expense of others.
I think that there is already plenty of incentive to create DBs and no further incentive is needed.
Here's real campaign finance reform.
1. Only people who can vote (registered) for a candidate can donate money to that candidate. This would keep corporate money, out-of-district money, and out-of-state money out of the election.
2. Only people registered with a party could donate money to that party. Partys could not give money to candidates; they could only use the money to recruit new members, run issue ads, and finance their conventions (i.e. party business).
3. No limit on the amount of money a person could contribute. Only exception would be a percent of annual income, say, 10%. This would keep rich people from donating money in the names of poor people. (If Joe Sixpack donates a million dollars given to him by his boss, but earned only $18,000 last year, both could be prosecuted under election laws.)
4. No limit on spending by a candidate with donated money. Limit spending his own money to 10% of annual income.
5. Full and immediate disclosure of all sources of donations. This would let the voters see exactly who is trying to buy a candidate and let them decide accordingly.
So, if I were running for mayor of Anytown, USA, I could spend 10% of my annual income and all of the money donated to my campaign by citizens of Anytown who were registered voters. No money would be allowed from out-of-town corporations, etc..
If I were running for the U.S. Senate, I could accept money from any registered voter in my state.
Does money win elections? Ask President Steve Forbes.
The rules outlined above are not perfect, but wiser people than me could tweak them a bit.
BTW you did a fair job of this with your 'true capitalism == libertarian' statement, I am not knocking your post specifically.
Side note, would the berne convention require other countries to honor this copyright??
Grumble... apparently the -q 10 option to oggenc overrides the -b 128 option. it actually was encoded at about 500kbps. I need to rerun everything to double check.
In audacity the waveform looks like a flat line. Just a little bit thicker than silence. Playing it sounds something like wind going through trees. Lots of scratchy stuff.
I also comapred the original wave file to the mp3. The difference between the origonal wave and the mp3 is at least an order of magnitude (10x) larger than the difference between the mp3 and the transcoded ogg. For example, I amplified the original wave as far as you could without clipping before this test. I could have amplified the diff of the mp3 and ogg by 24.0 db without clipping.
commands used: lame --abr 128 file.wavoggenc -b 128 -q 10 file2.wav (full quality)
file2.wav was exported from audacity using the imported mp3.
My conclusion, If you can't tell the difference between the original wav and the mp3, there is no way you will ever tell the difference between an mp3 and the ogg made from it, even using better speakers/amp etc, as long as the bitrates are the same. This was not an exhustive test, different songs/frequencies may be different YMMV, but I would not be afraid to transcode my stuff.
Ummmm, have you tried it? I know the theory, but I tried it just for fun. as long as the ogg was the same bitrate as the mp3, I could not tell the difference. Maby I'll do just that again, and then import both into audacity and do a diff to see what if any real difference there is.
You must be using windoze, 'cause under linux, rec (a front end to sox) is a simple command-line program that does exactally that.
1.2-pre-1 at least, has a remove noise effect. It looks like it is for removing hiss and similar noise.