How can I convert audio files to mp3 with original file's audio quality?
ffmpeg -i audio.ogg -f mp3 newfile.mp3
I want to know is that code converts with same quality?
it is impossible. FFmpeg cannot search for you input file's bit rate and then cannot copy funded bit rate to output. We need to find the input file's bit rate then we need to convert to mp3. This code converts audio files to mp3 with 320 kbps bit rate.
ffmpeg -i 31352.m4a -ab 320k -f mp3 newfile.mp3
Related
I am using ffmpeg to create an hls stream. The source is an mkv with multiple audio tracks. I have tried using -map to specify the audio stream as well. I also found that when I point ffmpeg to any other audio stream in the file it works. It's just the first audio stream that does not. At one point I replaced -c copy with -acodec aac -ac 6 on the first stream and I got sound which is great but I am only looking to copy the stream and not re-encode it. The next thing I tried was using other mkv videos I have. All are reflecting the same issue. The mkv's by itself play both audio and video fine in VLC. When playing the output.m3u8 in VLC the option to choose different audio tracks is greyed out. Here is the command I'm using:
ffmpeg -i "./video.mkv" -ss 00:00:00 -t 00:00:30 -c copy -f hls "output.m3u8"
I want the audio of my hls stream to reflect that of the mkv source:
Although what I get returned from the command above gives me no sound and shows me this in mediaInfo:
I've aslo noticed that hls does not support pcm. Is it possible dash could work with this stream because it is pcm?
HLS segments can be either MPEG-TS or fragmented MP4. Neither officially support PCM audio, so you'll have to convert it.
DASH uses fragmented MP4 as segment format.
I'm converting .flac and .mp3 audio files to .m4a using ffmpeg with libfdk_aac (Fraunhofer AAC encoder) like this:
ffmpeg -i "001.flac" -c:a libfdk_aac "001.m4a"
This works fine, but in case of .flac the resulting .m4a files include ~0.046 seconds of silence at the start and sometimes a few extra milliseconds at the end. Though, I need the .m4a files to be of exactly(!) the same length without any extra silence. Is there a way to achieve this?
EDIT: At the moment I'm using an additional step, i.e. cutting the resulting .m4a file works at least in the beginning of the track, but there are still some (varying) extra ms in the end:
ffmpeg -i 001.m4a -ss 0.047 -c:a libfdk_aac 001cut.m4a
No, it’s not possible. The different codecs use different frame sizes.
I don't expect this to happen often, but while re-encoding video files via batch file to h265 I'm checking to make sure the audio is in aac. If it isn't then I want to convert to aac, but keep the bit rate at what ever the old file uses since if I just convert to aac ffmpeg is going to use the default 128kbps value. For any old videos I have the bit rate is probably going to be lower than that so upconverting is going to increase the file size a little.
Is there any way to convert to aac but keep the old bit rate?
Here's what I was trying but it keeps converting the old mp3 89kbps stream to aac 128 kbps:
ffmpeg -i test.mp4 -acodec aac -vcodec copy test.aac.mp4
Note that above is just for test purposes, I am actually converting the video.
Note 2: My question isn't at all similar to the other question that it has been suggested as similar to. I have no trouble storing ffprobe results in variables nor did I even mention that.
You could detect the bitrate of the audio stream from your input file using ffprobe, and then depending on the output from that command run the appropriate FFMPEG command.
Here's a small bash script that will detect the bitrate on the audio stream and if it is less than 128Kbps just use that original bitrate during conversion. This should avoid up sampling:
#!/usr/bin/env bash
AUDIO_BITRATE=`ffprobe -v error -select_streams a:0 -show_entries stream=bit_rate -of default=noprint_wrappers=1:nokey=1 $1`
if [[ $AUDIO_BITRATE < 128000 ]]; then
ffmpeg -i $1 -acodec aac -ab ${AUDIO_BITRATE}k -vcodec copy new-$1
else
ffmpeg -i $1 -acodec aac -vcodec copy new-$1
fi
Alternatively if you need to convert into other video formats and don't have FFMPEG installed you could use a commercial conversion API such as Zamzar.
We're converting a bunch of .RM files to .MP4 and wondered what the best way is. Here are the details:
Convert the files to H.264.
Keep the filename but add .mp4 to the end.
Also extract a JPG image of the video at about 5 seconds in for each file and name it the original filename + .jpg.
This is on a Windows system. Is there a free tool you recommend for this? Thank you.
ffmpeg is pretty much the defacto standard app for transcoding video.
http://www.ffmpeg.org/
Convert to h264/mp4:
ffmpeg.exe -i inputFile.rm -vcodec libx264 -s 320x240 -acodec libfaac outputFile.mp4
I am using the following command to convert FLV files to audio files to feed into julian, a speech to text program.
cat ./jon2.flv | ffmpeg -i - -vn -acodec pcm_s16le -ar 16000 -ac 1 -f wav - | cat - > jon2.wav
The cat's are there for debugging purposes as the final use will be a running program that will pipe FLV into ffmpeg's stdin and the stdout going to julian.
The resulting wave files are identified by "file" as:
jon3.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 16000 Hz
VLC (based on ffmpeg) plays the file, but no other tools will open/see the data. They show empty wav files or won't open/play. For example Sound Booth from CS4.
Has anyone else had similar problems? Julian requires wav files 16bit mono at 16000 Hz. Julian does seem to read the file, but doesn't seem to go through the entire file (may be unrelated).
Thanks,
-rr
Try having ffmpeg directly operate on the input/output files, instead of piping data into and out of ffmpeg:
ffmpeg -i INPUT_FILE.FLV -vn -acodec pcm_s16le -ar 16000 -ac 1 -f wav OUTPUT_FILE.WAV
The problem may be that because you are feeding ffmpeg a stream, and asking it to write a stream, it either does not know the input stream's length, or, more likely, it cannot go back and rewrite the length data in the header of the output file.
The problem is likely that with RIFF, bytes 4 through 7 is where the file length (bytes) is stored which, at the time it is being written, is not yet known. VLC likely ignores the value from the RIFF header allowing it to play there, but not play elsewhere.
The only solution I found was to modify the target to ignore the length from the RIFF header as well.
The structure of the Wave File Header is described here:
http://www.sonicspot.com/guide/wavefiles.html