I am creating one application in Android. My application record audio and store it on SD card
and show in list format. I do this all but i need to edit this audio like suppose i open recording
then i need to start this recording again from ending and able to append audio in that recording.
Like: Suppose my recoding "MyRecord01" time is 04.06 sec and i want to add more audio in the recording
then it must start from 04.07 and add some audio.
I search lot of but didn't find anything relative. Please direct me to any link or any reference.
Or give me any hint.
Thanks in advance.
Here is the code you need. Hope it works for you.
If I identified your problem wrong, feel free to comment and tell me.
This is not too difficult. The key is to understand how the audio you've recorded is formatted. It's easiest if you use an uncompressed format, like WAV or AIFF. Here is one (of many) explanations of the WAV file formats: https://ccrma.stanford.edu/courses/422/projects/WaveFormat/
Most WAV files can be easily appended to if the data chunk is last (this may be a requirement of the format, I can't recall for sure). If it is not last, you'll first have to copy the file and modify it such that the data chunk is last. This can be a time-consuming step if the file is large.
Once that's done, you simply append new audio data to the data chunk and update a few pieces of data elsewhere in the file, such as the data chunk size (in the the data chunk), the chunk size (in the RIFF descriptor) and the Subchunk1 size (in the fmt chunk). (That will all make more sense to you once you read the explanation.) You may want to do something with those data while you are appending so that it is easy to fix in case your app crashes durring the append -- you don't want to corrupt the user's data.
The process is similar for AIFFs, but there are differences in the details.
For MP3s, I am not 100% sure off the top of my head how this would work. If memory serves the process is conceptually easier because MP3 files are structured as a series of independent chunks, and each chunk has its own mini header. Theoretically, you can just append more chunks. In practice it is going to be more complex, though, because of the compression and things like ID3 tags.
Related
I am developing and android app for text to speech conversion for regional language and for that I am storing basic audio sounds for pronunciation of words. Whenever a character is read from file the corresponding audio file is chosen for waveform generation. hence a single audio file is fetched so many times even for small amount of content in file. So here my question is where I'll have to store that audio files such that loading can be as fast as possible?
What folder its in won't make a real difference, so long as you unpack it from assets (assets being compressed). What would make a difference is storing it in memory vs on disk. Of course that depends on how many/how big of sound files you actually use- do you have one per word, one per phoneme, or something else? My guess is you'll actually have better performance if you combine multiple phonemes into a single waveform for playback rather than try to play each individually.
How can merge two sounds and save as a new file?. One sound is a loaded mp3 file and the other from the microphone. Then I need to upload this sound into a server. Is this possible?
This all can be done, but if you looking simple example with few methods to call, I'm afraid it's not so easy.
You can extract bytes from sound with Sound.extract(). This data is sound amplitude in 16-bit numbers, right and left channel interleaved. Use ByteArray.readShort() to get them.
Microphone data can be captured with SampleDataEvent.SAMPLE_DATA, see example here. To mix them with song, just add sound amplitudes and write result into third array. The result will be essentially WAV-format (without header,) unpacked sound data. You can upload it raw, or search for "as3 mp3 encoder" (google), but these things are rare and written by entusiasts, so maybe you can get them work. Also, to mix sounds correctly, frequencies of data from mic and sound file must be equal.
And upload part - if this was file on disk, this would be easy - FileReference.upload(). But there's only data in memory. So you can look into Socket class to send it.
In order to process a FFT on an audio signal, I first need to convert my audio file into an array of complex numbers. I still don't understand if this part requires to save a .CSV of .TXT file on my sd card or if I can simply stock data in my application as a variable.
I would simply like to understand how this part really works in order to go further in my FFT program : from my .3gpp audio file (by the way, is it a good format to use for what I am doing?) saved on my sd card, what should I do to have my array of complex numbers, the input for the FFT ?
If anyone has an example of existing code used to convert audio file to binary data, I would really appreciate to take a look at it and to understand how to implement it in my activity.
I need to implement a playback of separate audio files in N channels, files may play sequentially or in parallel. I need to implement it on Android.
Timeline:
|file a...|file d....|file b...|......|file k|....
|.....|file g|file c..|file p.|....
I'm thinking two options, one being FMOD to decompress files and play them simultaneously. I have researched and FMOD seems to fit well and much easier than manually playing this using an AudioTrack. However, I can't understand if FMOD would allow us to save the entire merged output without playing it through.
I know that using solution here we can redirect output to a wav file, but is it possible to just create a final output instantly and save it using FMOD? Or will I have to manually merge PCMS into one stream after all..
Thanks.
An important question here is why you need to save the files out, if it's possible to do this offline then it would be a lot simpler. If you must record the concatenation of several files (including others played in parallel), it is quite possible with FMOD.
One way would be to use wave-writer-nrt output mode, which allows you to output a wav file based on FMOD playsound calls in faster than realtime.
Another way is to use a custom DSP to access the data stream of any submix as it plays, useful if you want other sounds actually playing at the same time.
Another is simply create the sound objects, then use Sound::lock to access the PCM data, which you could concatenate yourself to a destination. Keep in mind all the sounds would need to be the same sample rate and channels, otherwise you would need to do processing. Also keep in mind you cannot do this for parallel sounds unless you want to mix the audio yourself.
Folks,
The project that I am working on requires that a certain video can be played on an android device for x number of times. After that, it must stop playing. When a client gets the video file, he or she also gets another file that contains the Android device ID and the number of times the video can be played. The original file and the metadata file are both encrypted.
My first thought is just to write a video decoder for the video file. Each time the file is played, the decoder first checks if Android device and the count are valid, decrements the count, starts decrypting the data and streaming it to the mpeg-4 decoder shipped with the OS.
I would appreciate your feedback on this idea. Please share your thoughts if you feel there is a better way to do it.
One problem I see is where to store the actual count. Storing it in the file itself won't work as the user can simply backup the original file and replace it after the count exceeds. It has to be stored in some other part of the system that cannot be tampered by the end-user.
Thank you in advance for your help.
Regards,
Peter
Useless to store it anywhere on the actual device, because anywhere an app can touch a user can as well. Best bet is to use a remote server for authorization, but then you get spoofing problems. But your real goal is to make it a nuisance, not worth going around, instead of making it impossible to crack, because you can't.
Okay, the simplest way would be similar to something you first suggested, and needs no further infrastructure: store the information in a file. This is defeated by reloading the file, as you suggested, but even that is a high enough barrier for some.
Defeat reloading the file via obsfucating where you're storing the information. Possibilities include text files (easy to spot), or perhaps image files (like images that are supposedly button images).
Remember, it only takes 1 guy 1 time to point the playback into a recorder, and you have a perfect, DRM-free copy running around in the wild. Remember that you're simply trying to make it easy enough to view legitimately and difficult enough to crack (take the difference of those) that people won't bother cracking it.