Your best bet is to see what formats youtube-dl returns by running at a command-line,
youtube-dl -F URL
which will produce output looking like this
format code extension resolution note
249 webm audio only DASH audio 53k , opus @ 50k (48000Hz), 4.25MiB
250 webm audio only DASH audio 72k , opus @ 70k (48000Hz), 5.53MiB
What I'm wondering is why does the algorithm decide to put the random values at the front of the first chunk instead of the end of the last chunk? I'm also wondering, why are the random values random? Why can't the encoder just use 0.0?
The noise is almost certainly coming from the decoder not the encoder. The encoder processes the audio and produces a set ...
This is an anti-aliasing filter. The --preset insane settings must allow aliasing to become apparent.
Your iPhone can't reproduce the frequencies the filter is applied to anyway, and if it could, you wouldn't hear them.
Disabling the filter would likely lead to a very slightly larger file, and some unwanted (lower) frequencies caused by aliasing. An anti-...
Industry level audio usually heavily compressed as a last step of production. I would guess this is what you are after. This is of course given your initial sound track is of decent quality already. There are plenty of software compressors available on the market and can be used with Logic. I'm not recommending or advertising but just for example.
neroAacEnc is also available for Linux. If you find that is works for you in OS X then you can use ffmpeg to pipe to this encoder and then mux with ffmpeg:
ffmpeg -i input -f wav - | neroAacEnc -ignorelength -if - -of audio.mp4
ffmpeg -i video.mp4 -i audio.mp4 -c copy -map 0 output.mkv
However, FFmpeg now also supports the external encoding library from ...
8-bit 8K isn't going to be great quality in any case, but WAV is as good as you can do. Straight uncompressed MS-format (RIFF) WAV is the most compatible format for interchange.
There are two senses of 'compressed' at work here. U (mu)-law and A-law refer to schemes for compressing dynamic range, not for reducing file size. Typically they would be 'expanded'...
Yes, certain compression formats can result in higher peak levels than the same material pre-compression. -1dBTP ("true peak" level, relative to full scale) seems to be the accepted maximum safe level for pre-compressed material when considering this. It's important to ensure you are infact analysing true peak (aka. inter-sample peak) level and not sample ...
The Binary Revolution Stream format uses ADPCM to represent audio data. ADPCM uses a lossless compression algorithm.
ADPCM is an adaptation of DPCM, which is in turn, an adaptation of PCM.
Differential pulse-code modulation (DPCM), like PCM, uses a cyclic pulse to sample a given waveform at discrete intervals. But instead of simply quantizing and storing ...
From a quick read through several of the links above, I believe it's most appropriate to call BRSTM a lossless audio format. For a start, let's define "lossless audio":
For simplicity's sake, a lossless audio format is an audio format where the bits going in (during recording) match the bits going out (during playback).
To explain ADPCM (and I'm by no ...
According to the man page, --bps specifies the bits per sample. As far as I can tell, this parameter controls the data that will be encoded using FLAC, and can have a lossy effect. For example, here's a comparison of a short audio clip using 8, 16, and 32 bits:
You should never use 8 bits unless you're going for an effect, ...
It does not make sense. You get a lot bigger filesizes, precisely 620 MB per hour of audio (which translates to 20 3-minute-long songs). For thousands, you're looking at about 60 GB of music. A minute of uncompressed audio is 31 MB. For an average American (source), that's 13 seconds of loading a single minute of audio. Not to mention 31 MB of data from a ...
Yes, you ALWAYS lose quality when open a file created with lossy compression (i.e. virtually all flavors of MP3) It may not be very much, but it is unavoidable. That is why it is called "lossy".
HOWEVER, when you RE-compress the track back through another lossy compression process, you run significantly more risk of loss. Because you are applying the ...
Just an idea (which needs further research): do you actually need the silence to be a file or could you just play dynamically created data? If the latter is the case, you could probably find a solution to call a program that creates a silent audio file in realtime and put that in your playlist. That way you would entirely get around the file size issues for ...
I would highly recommend using CELT or Opus for low bitrate audio (48kbps-96kbps), it sounds far superior, even compared to high performance ACC-HE+. the later is an IETF standard, and already widely supported.
Both support CBR, ABR (CVBR), VBR.
Vorbis supports VBR, ABR.
ffmpeg documentation for Vorbis and Opus have easily defined options for ABR control.
Although FLAC encoding is always lossless, it still offers different compression levels to choose a tradeoff between size and decoding speed.
So, the unexpected difference in size that you noticed may come from different compression levels between the files.
Try to re-encode the cropped file with maximum compression level (8) and compare sizes again.
--preset insane seems to be using a lowpass filter as well...
see LAME: Why is a lowpass filter used with --preset insane
Opus is a much newer, state of the art technology than MP3. Any time you encode audio into MP3 or Opus, you never get a perfect, exact copy of the original file. There is always some distortion added and some things missing. This is by their design. They are not meant to perfectly preserve all of the information, they are meant to make small files. To answer ...
You should be able to create a Mix-Down directly in Cubase, without having to re-record your audio in Audacity and then encode it with Nero.
To export and audio file in Cubase, follow the following steps:
There you should have all the options you need, like File Format, Audio Engine Output and all related settings.
I'm also ...