search

lordmulder / LameXP

Audio Encoder Front-End
http://lordmulder.github.io/LameXP
Other
184 stars 18 forks source link

WebM container support #51

Closed georgiptr closed 7 years ago

georgiptr commented 7 years ago

Downloading Opus audio with youtube-dl results in Opus stream inside WebM container as it is served this way from Youtube. Unfortunately such files can't be imported in LameXP as it doesn't support WebM container. Can you please add support for it? Of course I'll donate. :) Also an interesting question would be - could LameXP support just repacking from WebM to OGG without transcoding?

lordmulder commented 7 years ago

WebM is a video file standard. It is nothing Google's VP9 video format multiplexed with Opus audio and wrapped in a Matroska container. The "official" Opus decoder from Xiph.org, which is used by LameXP, doesn't support Matroska container to the best of my knowledge. Xiph.org uses their own "Ogg" container.

georgiptr commented 7 years ago

As far as I understand WebM is a container with a subset of Matroska features. webm stands for Web Media (not Web Matroska). It is a subset of Matroska with only the necessary features required for video (and audio) to play over the web.

My question can become more generic then - does LameXP support Matroska container as input? I am not sure how LameXP works internally, but I doubt it uses the "official" Opus decoder from Xiph.org directly as LameXP is input-codec agnostic. For example when the input file is MP3 and the output uses the Opus codec, it should decode the MP3 first. I imagine it uses ffmpeg to do so and ffmpeg supports Matroska as an input format.

lordmulder commented 7 years ago

LameXP is a GUI front-end for a variety of audio encoders (LAME, Vorbis, Opus, etc) and even more audio decoders. So your question is misleading. LameXP does support the Opus audio format - for encoding (output) as well as decoding (input). Opus support is provided by opus-tools, which is the "official" Opus encoder/decoder software provided by Xiph.org (who are the creators of the Opus format). But opus-tools does not seem to support "Matroska" container. That's because Xiph.org has their own container, which is called "Ogg" and which is what is normally used to store Opus streams (as well as Vorbis streams).

georgiptr commented 7 years ago

How is decoding related to the codec used for encoding? For example opus-tools's opusenc supports only "WAV, AIFF, FLAC, Ogg/FLAC, or raw files" as input. If the input is AAC or MP3, LameXP should decode it first to WAV before feeding it to opusenc. Also just drag'n'droping the input file to LameXP results in parsing this file just to add it to the list of files to encode, which is again unrelated to what the file will be encoded to.

For example including MKVToolNix support inside LameXP which will allow using Matroska containers as input.

lordmulder commented 7 years ago

How is decoding related to the codec used for encoding? For example opus-tools's opusenc supports only "WAV, AIFF, FLAC, Ogg/FLAC, or raw files" as input. If the input is AAC or MP3, LameXP should decode it first to WAV before feeding it to opusenc.

Yeah, and that's exactly what is done :smirk:

The format of the input file is detected, via MediaInfo and then the proper decoder tool is selected. For example, if an MP3 file is detected, it will be decoded to WAV using mpg123 tool. If an AAC file is detected, it will be decoded to WAV using faad tool. If a FLAC file is detected, it will be decoded to WAV using flac tool. If an Opus file is detected, it will be decoded to WAV using opus-tools suite. And so on...

Opus tools does not support MKV container, only Ogg container - which is the "native" container for Opus audio format. Surely, we could integrate MKVToolNix to extract the tracks from MKV container. But an MKV file may contain pretty much anything. This would require a completely new strategy! Instead of detecting the file format once and then let the proper tool decode the file, we would need to implement "recursive" decoding: Detect the format of the file, then invoke the proper tool to extract the tracks from container, then detect the format of the extracted files, then invoke the proper tool to decode the extracted files. But this would be a rather big change of how the program works. Also there are many open questions: What if the "extracted" track again is in some container format that the decoder can not handle directly? What if there are many audio tracks in the, e.g., MKV container - maybe in different audio formats? etc. pp.

I don't say it's entirely impossible to implement. But it certainly is not something that can be added easily.

georgiptr commented 7 years ago

I understand. Thank you for explaining the process. Now I see that implementing recursive decoding to handle MKV will require a lot of work. Thank you for your time. I suppose the issue can be closed now.