@Jennings92, welcome to the forum. Let me offer a somewhat different set of answers to your questions:
- You have apples and oranges sloshing around: AAC and mp3 are audio specifications (mp3 can also be used as an audio container format), while webm and mkv are video container formats. This can quickly get confusing, but here is a synopsis:
container or file specification - this describes the way various data streams (audio, video, subtitles) and metadata are written together into a single file. In general, a given container is capable of containing data that has been encoded in different ways; for example, an .mp4 container might have a video data stream encoded by the h.264 standard or by the h.265 standard. When you see a file with the .mp4 or .webm extension, you are looking at a container; you have to dig to find out what data streams it contains and how they are encoded.
data stream specification - various standards have been developed to describe the way that audio and video can be encoded and compressed. h.263, h.264, and h.265 are commonly used video standards, but all of these involve patents and royalties. Theora is an open source (FOSS) video standard. VP8, VP9, and AV1 are video standards owned by Google, but they have declared the patents irrevocably public domain, or something like that - royalty free, in any case. Some common standards for audio include AAC, mp3, FLAC, AC3 … and that list goes on and on.
codec - the software or hardware that implements the encoding and decoding based on a certain standard. Note that “codec” is often used synonymously with “standard,” because they are closely connected … but they are not the same. There are several codecs that implement the h.264 standard, including DivX, x264, and various hardware codecs built into AMD and NVidia GPUs.
lossy vs. lossless compression - As far as I know, there are no video standards that do not involve some type of compression; otherwise, the storage and transmission of digital video would be overwhelming - it would take something like 11GB per minute for a 1080p video using 8-bit color depth. At a minimum, one can compress the video data stream using a lossless algorithm (along the lines of a .zip file); this might reduce the stream to something like 1GB per minute, but that’s still a lot of data to try to push across your wifi connection. The real secret of everything from DVDs to YouTube is to use lossy compression, which can achieve tremendous amount of compression at the cost of losing a small bit of detail. To see what this means, zoom in to the pixel level on a picture stored in a RAW format (lossless compression) vs. one stored as a .jpg - the latter will have some fuzziness that you don’t really notice when you are zoomed out for typical viewing. Using lossy compression, a 2-hour movie can be compressed into < 4GB to fit on a DVD. All of the most commonly used video standards - h.263, h.264, h.265, VP8, VP9, etc. - use lossy compression. Note that audio is much less “expensive” than video, so there are some uncompressed (e.g., PCM) or lossless compressed (e.g., FLAC or ALAC) audio formats, but again the most commonly used, such as MP3 and AAC, are generally implemented as lossy compression.
- 1a. You can never convert to or from a lossy format without losing something. You might improve the audio quality by doing some filtering, but you cannot improve the quality simply by re-encoding, even if you re-encode with a “better” standard, higher bit rate, etc. I would guess that anything downloaded from YouTube has probably already gone through a couple of encoding cycles, so the data (both audio and video) is already degraded. The only way not to degrade it further is to copy it rather than to convert or encode it. If you do need to encode it (e.g., because you are editing it), make every effort only to do it once. The more times you decode / encode, the more it will degrade.
If ALL you want to do is to encode / convert the data streams and/or containers, then Shotcut is overkill. That said, yes, you can use it for this purpose.
I tried the free version of DaVinci Resolve and found it much harder and more confusing to use than Shotcut. It also did not work correctly when I tried to run it on a virtual machine - may be a minor point for most, but in the specific use case for which I was testing it, that was a fatal flaw. (Shotcut worked fine on the VM.)