I am using the JSpeex API to convert a .wav file into .spx file. Everything goes perfect when tested on desktop; it took only 2 seconds.
Android developer used the same code but it took around 3 minutes to encode the same file on their simulator & phone. Is there any way to reduce this time for encoding? Code used to convert is as follows:
new JSpeexEnc().encode(new File("source.wav"), new File("dest.spx"));
Compression takes time. The better the compression, the longer it takes, and Speex is pretty good compression.
2 seconds of desktop computer time is absolutely ages.
JSpeex is a java implementation. Use a native implementation, ideally use the platform codecs, instead.
On phones, speech is best compressed using AMR - not necessarily the best quality/compression, but most likely hardware accelerated since its the format used by GSM. You can usually get AMR straight from the microphone.
How do you get large WAV files onto an Android device in the first place? If its actually the output of the microphone, consider using AMR as outlined above.
If you need Speex and you have a wav file, then consider sending it to a server for compression.
Related
I have a Java application that needs to play a few distinct 'sounds/riffs' to indicate status. I would like to know whether it is better to record these as audio files (wav or whatever format) and play them back using the Java audio classes, or whether it would be better to store MIDI data and play them using the Java MIDI classes.
In my case, storage space is not a problem (within reason). I have about 5-8 status that I would like to play different melodies for. Each melody would be 1-3 seconds, consisting of 2-8 notes.
PCM (found within your WAV file) and MIDI are tools for entirely different jobs.
PCM is a way to encode audio, the sound itself. MIDI is a way to encode messages for controlling synthesizes... note on, note off, etc.
If you're playing back music and you don't particularly need high control over what it sounds like (as each system's MIDI synth can sound different), MIDI is an efficient way to encode it. If you need good quality instruments, vocals, etc., you need an actual sound format like PCM in WAV, MP3, AAC, etc.
I am working on a software that receives an MJPEG stream from an IP camera and displays it on the screen. Now I'd like to record the stream at the same time in some movie format.
I'm still quite new to Java and got a little lost in the jungle of libraries etc. that are available. What I found was JMF but it looks terribly outdated and unmaintained.
Does anyone here have any suggestions for proper video encoding libraries (must at least support Linux, but OS independent would be perfect)?
Thanks.
We have a requirement where we need to convert from .wav file to .mp3 and we are currently using "Tritonus" library to do that . The concern with that library is that requires "installation" of some "dll" files to the class path.
I am wondering are there any API's those allow better processing without local installation.
And other question is ,having mp3 format files will make it easier to join the files into a single file than having .wav files ?
As a former contributor to the JLayer MP3 Library, I'm fairly sure that it doesn't do WAV to MP3 - just MP3 playback and conversion to WAV. (I spent some time optimizing the decoder :-)
Regarding appending files (and possibly other operations), it is generally better to perform edit operations using the uncompressed format, and compress at the end.
I think the spec allows mp3 files to be concatenated, since they are a series of frames, but behaviour may vary from player to player.
So, to be safe, and maintain quality, I'd concat using WAVs and then compress the final result to MP3. Concating files is not so straightforward - you have to at least make sure they are at the same percieved volume, or you will get a noticible shift in volume from one file to the next. Such operations are definitely best performed on the uncompressed data.
The JLayer MP3 Library appears to support several operations on MP3 and WAV files including conversion, with no native libraries to install.
You can use MP3SPI to do this. This is a java sound plugin, just include the jar into the classpath, and you can use java sound api to convert between wav and mp3.
I wanted to find out how can one capture screencast using java. I know that using Robot class one can get a screenshot but how do I go about capturing it as a video and then uploading it to the server? How exactly would that work?
ideas?
With a pure Java solution, I doubt that it will work, but it depends of course on what your interpretation of "video".
On my desktop with a 1920x1200 resolution, I am able to get about 20 frames per second when using the Java Robot to capture the entire screen. Since each image contains >6 MByte of uncompressed data, I would need more than 1 Gbps bandwidth to transmit the raw data of these images to a server. Most probably, requiring so much bandwidth is not acceptable, so you either have to decrease the number of frames per second or apply some kind of compression to the images.
One possibility is to compress each image using one of the image formats supported by ImageIO. The size of the compressed images will of course depend heavily on what is actually shown on the screen, but the performance of the compressors is not particularly good. Compressing to PNG ought to give the best lossless compression ratio for most desktop content, but at least my computer is only able to process just about 2 frames per second. Using the JPEG compressor with default quality settings reaches about 5 frames per second.
Using common video codecs through an abstraction layer like jffmpeg will probably achieve both better performance and better compression ratio, but I doubt that mainstream video codecs like WMV or H.264 are suitable for common desktop content.
If you really require a pure Java solution (and are not able to use any of the available standalone software, which do what you're asking for), I would make an attempt to implement my own, simple compression algorithm. With common desktop activity, there ought to be very little difference between most consecutive screen shots, so what might work quite well is to transmit the first frame completely and after that implement an algorithm to roughly detect rectangles, in which changes have been made and then transmit only these combined with JPG or preferrably (quality) PNG compression.
Or use Xuggler, a better wrapper for FFmpeg in Java. In fact, the code for capturing the screen and encoding the video is one of the standard tutorials.
I'm also curious about this. https://www.screencast.com/ is currently doing just this with a pure java (or at least straight out of the browser) experience.
You can just use something like Java to a native FFMPEG build, and execute the command line at runtime. Here is an applet that I made that does just that: http://have2chat.net/screencast/
I have downloaded the main capture *.JAR file for the Screencast-O-Matic.com. To download the file:
Go to http://screencast-o-matic.com/jars/ScreencastOMaticRun-1.0.5.jar
Save the file
Extract the contents (I DO NOT intend to use this commercially!)
For the computer game I'm making, I obviously want to play sound. So far, I've been using AudioClip to play WAV files. While this approach works fine, the WAV files tend to be gigantic. A few seconds of sound end up being hundreds of kB. I'm faced with having a game download that's 95% audio!
The obvious option here would be to use MP3 or Ogg Vorbis. But I've had limited success with this - I can play MP3 using JLayer (but it plays in the same thread). As for Ogg, I've had no luck at all. Worse, JLayer's legal status is a bit on the dubious side.
So my question is to both Java developers and generally people who actually know something about sound: What do I do? Can I somehow "trim the fat" off my WAVs? Is there some way of playing Ogg in Java? Is there some other sound format I should use instead?
You could use JOrbis library to play back OGG music. For working sample usage you can look at these files here.
I also experimented with some lossless audio compression, for example I had a 16 bit mono sound. I separated the upper and lower bytes of each sample and put them after each other. Then I applied a differential replacement where each byte is replaced by its difference from the last byte. And finally used GZIP to compress the data. I was able to reduce the data size to 50-60% of the original size. Unfortunately this was not enough so I turned to the OGG format.
One thing I noticed with 8 bit music is that if I change the audio volume, the playback becomes very noisy. I solved this problem by upsampling the audio data to 16 bit right before the SourceDataLine.write().
These may be outdated, but they are officially recognized by the Xiph.org team (who maintain Ogg and Vorbis, among others).
http://www.vorbis.com/software/#java
The problem you describe is addressed by the Service Provider Interface (SPI) for sound in Java. The result is that simply adding JAR files to your classpath will add functionality to the default Java Sound API. Thus enabling the handling of more sound formats without changing code.
Last time I tried this the Javazoom people offered a working MP3 SPI JAR. Which was based on the JLayer you mentioned.
For Vorbis OGG there now also seems to be an SPI library. Check out the docs on the Vorbis SPI on Javazoom.
If you decide to stay with wav format...
It is probably not very important to have high quality sound files. You can use your favorite wav editor to lower the bit rate, switch to mono, or both. That will save tons of space and you won't notice the difference in quality while playing the game.
Hope this helps.