I am currently trying to play a encrypted .mp3 file. The way I am currently using is:
loading the encrypted file -> decrypting it -> save it to ISO -> play it with the backgroundaudioplayer.
But this can take up to 10-15 seconds to start one .mp3 file. Is there any other way to do this faster ?
For example is there a way to play from a stream and somehow decrypt it while playing ?
And is there actually the need for encrypting the files on the IsolatedStorage ? Since nobody should be able to touch them anyways ?!
Ok well since its been so long I would recommend "Buffering" its really easy, have your decrypt stream give you a decent sized buffer from the first 20 or so seconds of the file, that should take a few seconds max much faster than waiting for the whole file, then just simply feed the backgroundplayer using the decrypted buffer whilst the rest is still decrypting.
Related
I developed a socket based p2p system where i stream mp4 video from a client to a server. The video data are transferred using byte[].
The transfer works, however i am struggling to figure out how i could play, in continuous, a mp4 file being transferred to another PC? The PC application, that would play the file, is in WPF.
I tried using a MediaElement to play the file, being written to the disk, but for some reason it doesnt play at all. I can play it with VideoLan tho.
Any hint of where to look? I am lost from here!
Thanks in advance!
Its going to be different with every player. Mp4 is probably the worst possible container for this application. The container is designed to be used with random access media, such has a hard disk. The player has the ability, and sometimes requirement to seek around within the file, and not just plat start to finish. Either you need to make the protocol mp4 aware (parse the file, and download the block that will most like be needed next), or use a streamable container such as TS, or flv.
Its is also possible that the player knows the file is incomplete. The atoms sizes are encoded within the file. If the file size doest match, the combined atom sizes, the player could assume a corrupt file.If this is what is happening, you can try to pre allocate the file. it may trick the player enough to play
I encrypt my .mp4 into a custom format (.opu). Now I should decrypt my file and save them into temp folder at the start of my application. and play them using WindowsMediaPlayer control in C#. So I have the risk of stealing my files from temp folder. What is the best way to prevent stealing my files? How to play encrypted video file using WindowsMediaPlayer?
The best way would be to perform the decrypt to a stream in memory and play the video from there. That way there is never an on-disk file to steal.
There is a way using virtualization, i.e. hooks. The idea is to hook functions like ReadFile to provide decrypted data, SetFilePointer to maintain current pointer within a "file" etc. You can view one of the examples at http://www.boxedapp.com/encrypted_video_streaming.html
I am currently developing an application in C# to hide data in Mp3 audio files.
So far, I have been able to hide data in MP3 frames using the Least Significant Bit Approach (LSB). I can retrieve the data as well. The problem I am facing is, let's say I hide 300 bytes of data, the encoded audio plays just fine without significant noise. However when I try to encrypt more data into the MP3, like 500 bytes or more, there will be significant noise in my mp3 file. The audio gets distorted a lot.
I was wondering how to reduce that noise.
I am currently working on a project to hide data inside an mp3 file...What I did was, I replaced the last BYTE of every mp3 frame with the bytes from message file(the file to be hidden)... It works fine... I could hide the file in it and also successfully extract it... But some noise are present in the resulting mp3 file, due to addition of external data which is, definitely, not desired... Please help me in where to store the data in mp3 so as to reduce the noise...
PS: There is already a tool to use mp3 for hiding data -Mp3Stego. But it takes uncompressed wav file as input. But I need to have mp3 as input.
Such kind of tools do not replace whole byte. They are replace only last BIT. Try to replace only a BIT instead of BYTE. This will reduce the noise, but also reduce size of an information which you can put in file.
So the basic question is in encrypting files in resource constrained devices.
I have used a rather dangerous approach to use two FileStreams, where
FileStream 1 is reading from the file and copying it to a byte array
The contents of the byte array is encrypted.
FileStream 2, writes the bytes back to the same file.
This works fine but has a great chance of messing up a file if the encryption stops halfway etc.
So the normal approach is to write to a temp file, and then move it to the original location and replacing the original file.
However the problem is in mobile phones where resources (especially storage) are very limited, creating lets say another 200MB or 300MB file maybe impossible.
So what approaches are there to handle this problem in Mobile Devies? Do I have to gamble between space and messing up the file?
One way to make the process a little safer, could be to:
FileStream 1 is reading from the file and copying it to a byte array
The bytes you read, is written to a small "scratch" file the same size as your buffer, along with position of last block succesfully read.
The contents of the byte array is encrypted.
FileStream 2, writes the bytes back to the same file.
If the process is interrupted, check in the scratch file to see where your last position was. Then you can re-start the process from there, and still be able to encrypt the whole file. (And if you wanted to get the original file back, you would encrypt the remaining blocks, then decrypt it).
Of course, this process only works if you are using an encryption algorithm, that relies on the result of the preceding blocks when encrypting the current block. Depending on your choice of algorithm, you might need to store a little bit more.
First of all, you can always check if there is enough space to write your array to a tmp file.
Next, the problem you ask is not a real problem since if you're encrypting, you have read the complete file to array. Once encryption is finished, you can be sure that the byte array is encrypted. If this was not the case, the function would throw an exception. So, in step 3, when you write to file, you can overwrite it.
edit
I now realize that you encrypt and write to file partially since otherwise it wouldn't fit into ram. Is that correct?
Do I have to gamble between space and messing up the file?
Basically, Yes.
If space-constraints force you to convert (encrypt) in-place, there is no rollback option.
The next problem is Size. If your conversion (can) increase the size of the data, you have very limited room to maneuver. If ResultSize > (InputSize + Buffer) Then you're not going to succeed.
In the case of encryption, you can use a CompressStream in front of the CryptoStream, but you won't be able to predict if it's going to work.
In short, on a Mobile device you have reached a limit. You will have to mandate an extra Memory device.