search

lordmulder / LameXP

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

Opus + OGG support #24

Closed xtemp09 closed 8 years ago

xtemp09 commented 9 years ago

Could you add support for Opus in OGG? Opus has the best compression ever, OGG - a popular container which supports cover art and ReplayGain. I hope it will be implemented.

lordmulder commented 9 years ago

Opus streams are pretty much /always/ stored in Ogg container. At least that's what OpusEnc (and thus LameXP) creates. Note that OggOpus, i.e. the specification for Ogg-encapsulation of Opus streams, says that .opus is the recommended file extension.

https://wiki.xiph.org/OggOpus#Content_Type

Regards, MuldeR

On 18.08.2015 11:23, xtemp09 wrote:

Could you add support for Opus in OGG? Opus has the best compression ever, OGG - a popular container which supports cover art and ReplayGain. I hope it will be implemented.

— Reply to this email directly or view it on GitHub https://github.com/lordmulder/LameXP/issues/24.

xtemp09 commented 9 years ago

Does .opus equal .ogg? I.e. renaming will do the trick? Like mp4->m4a?

lordmulder commented 9 years ago

The file extension ist just a part of the file name. Renaming the file never is going to change its content (and thus it's never going to change its format). As explained before, the /recommended/ file extension for Ogg Opus files (according to the standard) is ".opus". Surely, you can rename those files to ".ogg" (latest LameXP also offers a way to that automatically for you). Those files would still be perfectly valid Ogg Opus files, as the file's content hasn't changed at all. But, does it make much sense to use a wrong file extension? Probably not! In most cases you should stick with the "correct" file extension, as defined by the Ogg Opus specification.

MuldeR

On 18.08.2015 11:56, xtemp09 wrote:

Does .opus equal .ogg? I.e. renaming will do the trick?

— Reply to this email directly or view it on GitHub https://github.com/lordmulder/LameXP/issues/24#issuecomment-132150735.

xtemp09 commented 9 years ago

Could you add cover art and ReplayGain calculation for ogg (opus) container? LameXP copies cover art when converting into mp3, but omits it in other cases.

lordmulder commented 9 years ago

What I actually can do is adding support for cover artwork for Opus files, because - in contrast to the Vorbis encoder (OggEnc2) - the Opus encoder (OpusEnc) does support an option for embedding cover artwork. I see no options regarding ReplayGain though. If you want any features to be added to OpusEnc, you'd have to ask the Opus developers, i.e. Xiph/Mozilla...

See also: https://mf4.xiph.org/jenkins/view/opus/job/opus-tools/ws/man/opusenc.html

MuldeR

On 18.08.2015 12:13, xtemp09 wrote:

Could you add cover art and ReplayGain calculation for ogg (opus) container? LameXP copies cover art when converting into mp3, but omits it in other cases.

— Reply to this email directly or view it on GitHub https://github.com/lordmulder/LameXP/issues/24#issuecomment-132156557.

lordmulder commented 9 years ago

The latest build has cover artwork embedding enabled for the OpusEnc encoder: LameXP-BETA.2015-08-19.Release-Static.Build-1784.exe

(Details: https://github.com/lordmulder/LameXP/commit/f663dcc75f0d76f041dc3d5b71f52d44f6790ed5#diff-56be4e718896627f3eaa04ace34a77b6)

xtemp09 commented 9 years ago

Many thanks; embedded art now seems to be working. I know that opusenc doesn't calculate ReplayGain, but it copies ReplayGain from tags of input file when converting by default. ReplayGain (and many others like total number of tracks on disc, disc number, BPM etc.) tags are missing after conversion. =(

lordmulder commented 9 years ago

"Retaining" the meta information isn't trivial to. The application, e.g. LameXP, must: (a) extract the meta tags from the original input file, (b) store the extracted meta infomration internally, and finnally (c) re-embed the stored meta information into the re-encoded file - provided the selected encoder supports this.

This all would be pretty easy to implement, if we had to deal with only one file format. But LameXP support N = 17 input formats and M = 11 output formats, leading to N x M = 187 combinations that all have to work! And of cours each format stores meta tags in its own specific format! MP3 doesn't support meta tags at all (though ID3, which now exists in various incompatible versions, is the de-dacto standard method to store meta tags in MP3), AAC stores meta tags on the MP4 container level (and of course Apple/iTunes does it differently than the rest of the world), Vorbis and Opus use VorbisComment, Monkeys Audio uses ApeTag, and so on...

Consequently, the internal meta data representation of LameXP is kind of a "smallest common denominator" of all the various file formats that need to be supported...

On 20.08.2015 10:41, xtemp09 wrote:

Many thanks; embedded art now seems to be working. I know that opusenc doesn't calculate ReplayGain, but it copies ReplayGain from tags of input file when converting by default. ReplayGain (and many others like total number of tracks on disc, disc number, BPM etc.) tags are missing after conversion. =(

— Reply to this email directly or view it on GitHub https://github.com/lordmulder/LameXP/issues/24#issuecomment-132939970.

xtemp09 commented 9 years ago

I beg to differ; there is always workaround, for example, ffmpeg and MediaInfo. ffmpeg is a small tool if video codecs are excluded during compilation; in the meantime it can have everything on input and produce WAV (and many other formats). MediaInfo is an extremely tiny tool that can read absolutely everything about media files.

I didn't go into the code, but I think that LameXP writes meta tags as Lame does (figured that out from its name). Opus tags - as opusenc, ogg tags - as vorbiscomment and so on. They have already been implemented. Or they can be replaced with ffmpeg, which might be the common denominator that supports all the tags by default.

LameXP is a Swiss knife; usage of common tools like ffmpeg and MediaInfo will make it Wunderwaffle, simplify inner structure and size of the program.

lordmulder commented 9 years ago

LameXP is a GUI front-end. In the background the proper CLI encoders or decoders are invoked. We already use MediaInfo to detect the file type (and thus select the proper decoder) as well as for reading the meta tags. But MediaInfo just dumps the meta tags as a list of key-value pairs. This needs to be parsed and stored in our internal data structure.

Of course our internal data structur cannot have fields for everytkind of info that might exist in some file of some format somewhere on the net. Instead we have to restrict to the things the are commonly used, in all file formats - such as "title", "artist" and "album". Also, LameXP needs to have the knowledge which key-value pair found by MediaInfo maps to which field of the internal data structure! For example, what is called "title=foo" in some files is called just "track=foo" in other files, but it all must all go to the "title" field of our internal data structur. Same for "artist=bar" and "performer=bar", which all has to go to the "artist" field of the internal data structure.

Furthermore, the selected output format predetermines which kind of meta tag (Id3, VorbisComment, MP4-style meta tags, ApeTag, etc) we must add to the file! For example, for MP3 we must use ID3, with all the implications and limitations that follow from ID3. And it is the individual encoder, e.g. LAME for MP3 or OpusEnc for Opus, which predetermines the tags that can be embedded at all (if any).

Finally, LameXP also must know how each tag from the internal data structure needs to be passd to the individual encoder. For LAME, e.g., the title must be passed as "--tt ", the <em>artist</em> must be passed as "--ta <artist>", and so on. At the same time, OpusEnc uses "--title <title>", "--artist <artist>", and so on. That's also the reason why it wouldn't make sense to have tag type in our internal data structure which are <em>not</em> supported by all encoders we use (or at least by the vast majority of the decoders). It only makes sense to store those tags that the encoders actually allow for embedding into the re-encoded file.</p> <p>Regards, MuldeR</p> <p>On 20.08.2015 15:28, xtemp09 wrote:</p> <blockquote> <p>I beg to differ; there is always workaround, for example, ffmpeg and MediaInfo. ffmpeg is a small tool if video codecs are excluded during compilation; in the meantime it can have everything on input and produce WAV (and many other formats). MediaInfo is an extremely tiny tool that can read absolutely everything about media files.</p> <p>I didn't go into the code, but I think that LameXP writes meta tags as Lame does (figured that out from its name). Opus tags - as opusenc, ogg tags - as vorbiscomment and so on. They have already been implemented. Or they can be replaced with ffmpeg, which might be the common denominator that supports all the tags by default.</p> <p>LameXP is a Swiss knife; usage of common tools like ffmpeg and MediaInfo will make it Wunderwaffle, simplify inner structure and size of the program.</p> <p>— Reply to this email directly or view it on GitHub <a href="https://github.com/lordmulder/LameXP/issues/24#issuecomment-133007343">https://github.com/lordmulder/LameXP/issues/24#issuecomment-133007343</a>.</p> </blockquote> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/xtemp09"><img src="https://avatars.githubusercontent.com/u/9303235?v=4" />xtemp09</a> commented <strong> 9 years ago</strong> </div> <div class="markdown-body"> <p>It's exactly what I meant; inclusion of ffmpeg will unify and simplify that work.</p> <p>The issue should be closed.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/lordmulder"><img src="https://avatars.githubusercontent.com/u/470590?v=4" />lordmulder</a> commented <strong> 9 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>It's exactly what I meant; inclusion of ffmpeg will unify and simplify that work.</p> </blockquote> <p>And it would pretty much mean a complete re-write of the software ;-)</p> <p>Also I think we use/support at least <em>some</em> encoders/decoders that are <strong>not</strong> in FFmpeg.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/xtemp09"><img src="https://avatars.githubusercontent.com/u/9303235?v=4" />xtemp09</a> commented <strong> 9 years ago</strong> </div> <div class="markdown-body"> <p>In the meantime, the majority of the encoders is in ffmpeg?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/lordmulder"><img src="https://avatars.githubusercontent.com/u/470590?v=4" />lordmulder</a> commented <strong> 9 years ago</strong> </div> <div class="markdown-body"> <p>The majority, yes. But if there is only one "external" encoder we have to call separately from FFmpeg, such QAAC or Nero AAC, we again need to have the meta data in our own data structure and we again need to know how each meta data field has to be passed to the encoder. So, unless <em>everything</em> is moved into FFmpeg, we don't win much by using FFmpeg.</p> <p>That plus: Audio filtering capabilities of FFmpeg or pretty minimal. Thus, a lot of things in LameXP are done with SoX. So we would need to do FFmpeg -> temp.wav -> SoX -> temp2.wav -> FFmpeg, in which case meta data is probably lost on the way. We would have to explicitely pass the meta tags to be embedded to FFmpeg in the last step. Which is pretty much the same "challenge" as before.</p> <p>Finally, I find it much preferable to be able to update each encoder or decoder separately, rather than having one big "monolithic" FFmpeg with a zillion of extra libraries included.</p> <p>On 21.08.2015 10:20, xtemp09 wrote:</p> <blockquote> <p>In the meantime, the majority of the encoders is in ffmpeg?</p> <p>— Reply to this email directly or view it on GitHub <a href="https://github.com/lordmulder/LameXP/issues/24#issuecomment-133327405">https://github.com/lordmulder/LameXP/issues/24#issuecomment-133327405</a>.</p> </blockquote> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/xtemp09"><img src="https://avatars.githubusercontent.com/u/9303235?v=4" />xtemp09</a> commented <strong> 9 years ago</strong> </div> <div class="markdown-body"> <p>When converting into OPUS I got the following errors. Though some of them are not related to OPUS, I put them here not to create additional issues.</p> <p><a href="http://pastebin.com/kzLzLCds">http://pastebin.com/kzLzLCds</a> <a href="http://pastebin.com/JntjU79m">http://pastebin.com/JntjU79m</a> <a href="http://pastebin.com/KNn0yTMC">http://pastebin.com/KNn0yTMC</a> <a href="http://pastebin.com/zzsreAMJ">http://pastebin.com/zzsreAMJ</a></p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/lordmulder"><img src="https://avatars.githubusercontent.com/u/470590?v=4" />lordmulder</a> commented <strong> 9 years ago</strong> </div> <div class="markdown-body"> <p><strong>Error 1</strong></p> <blockquote> <p>When converting into OPUS I got the following errors. Though some of them are not related to OPUS, I put them here not to create additional issues. <a href="http://pastebin.com/kzLzLCds">http://pastebin.com/kzLzLCds</a></p> <pre><code>C:/Users/AMS/AppData/Local/Temp/0c6133a06a101e3e/lxp_opusenc.exe --vbr --comp 10 --framesize 20 --bitrate 96 --title "Towers Of The Void" --artist "Brian Reitzell" --album "Red Riding Hood: Original Motion Picture Soundtrack" --genre Soundtrack --date 2011 --comment tracknumber=1 --picture C:\Users\AMS\AppData\Local\Temp\0c6133a06a101e3e\cad31cc184446b51.jpg C:\Users\AMS\AppData\Local\Temp\0c6133a06a101e3e\4af982e6384aaaa2.wav "F:\Downloads\Temp\music\Soundtracks\OST Red Riding Hood\01 - Brian Reitzell - Towers Of The Void.opus" Error parsing picture option: unable to guess MIME type from file, must set it explicitly</code></pre> </blockquote> <p>This means that Opus was <strong>not</strong> able to determine the type of your image file. It means your image file is neither a valid JPEG, PNG or GIF file. I could try to set the MIME-Type <em>explicitly</em>, to shut up the OpusEnc error. But it would mean that we are embedding an possibly invalid/unsupported image file.</p> <hr /> <p><strong>Error 2</strong></p> <blockquote> <p><a href="http://pastebin.com/JntjU79m">http://pastebin.com/JntjU79m</a></p> <pre><code>C:/Users/AMS/AppData/Local/Temp/0c6133a06a101e3e/lxp_opusenc.exe --vbr --comp 10 --framesize 20 --bitrate 96 --title "One Tender Kiss (The Lost Seasons) - Prelude to the Garden of Crystalline Dreams" --artist "Autumn Tears" --album "Love Poems for Dying Children" --genre "Neoclassical Dark Wave" --date 2008 --comment tracknumber=8 --picture C:\Users\AMS\AppData\Local\Temp\0c6133a06a101e3e\54901f7482be10f4.jpg C:\Users\AMS\AppData\Local\Temp\0c6133a06a101e3e\8c08aa41ce8d5e83.wav "F:\Downloads\Temp\music\Darkwave\Autumn Tears\1996 - Love Poems for Dying Children Act I - 13th Anniversary Edition CD1\1996 - Love Poems for Dying Children Act I - CD1\08 - Autumn Tears - One Tender Kiss (The Lost Seasons) - Prelude to the Garden of Crystalline Dreams.opus" F:\Downloads\Temp\music\Darkwave\Autumn Tears\1996 - Love Poems for Dying Children Act I - 13th Anniversary Edition CD1\1996 - Love Poems for Dying Children Act I - CD1\08 - Autumn Tears - One Tender Kiss (The Lost Seasons) - Prelude to the Garden of Crystalline Dreams.opus: No such file or directory Encoding using libopus 1.1.x-git IA32 [2015-03-26] (audio)</code></pre> </blockquote> <p>The error "No such file or directory" means that the file you are tying to convert no longer exists. The file probably has been moved, renamed or deleted since you "loaded" it into LameXP.</p> <hr /> <p><strong>Error 3</strong></p> <blockquote> <p><a href="http://pastebin.com/KNn0yTMC">http://pastebin.com/KNn0yTMC</a></p> <pre><code>C:/Users/AMS/AppData/Local/Temp/0c6133a06a101e3e/lxp_faad.exe -o C:\Users\AMS\AppData\Local\Temp\0c6133a06a101e3e\e72299508501f4dc.wav "F:\music\Darkwave\Autumn Tears\1996 - Love Poems for Dying Children Act I - 13th Anniversary Edition CD1\Data\Interview1996.mov" Unable to find correct AAC sound track in the MP4 file.</code></pre> </blockquote> <p>This MOV/MP4 file is corrupted! Either that, or it's an "exotic" kind of MP4 file that FAAD cannot handle. In the latter case, only the FAAD guys can fix it. However, development of FAAD is pretty much dead.</p> <p>(I'm assuming you are <strong>not</strong> trying to convert a Video-only MP4 file. Are you?)</p> <hr /> <p><strong>Error 4</strong></p> <blockquote> <p><a href="http://pastebin.com/zzsreAMJ">http://pastebin.com/zzsreAMJ</a></p> <pre><code>The format of this file is NOT supported: F:/music/Rock/Power metal/Арда/2007 - Море исчезающих времён/data/arda - exorcist.mpg Container Format: MPEG-PS</code></pre> </blockquote> <p>As the error message says, <em>MPEG-PS</em> files are <strong>not</strong> currently supported! Use <a href="http://www.videohelp.com/software/DGMPGDec"><em>DGIndex</em></a> to demultiplex the <em>audio</em> part from this <strong>video</strong> file. Then you should be able to process it in LameXP.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/xtemp09"><img src="https://avatars.githubusercontent.com/u/9303235?v=4" />xtemp09</a> commented <strong> 9 years ago</strong> </div> <div class="markdown-body"> <p>Error 1: It's just a JPEG file; it was embedded with TagScan and is seen by any player.</p> <p>Error 2: I don't delete files before conversion. My guess is that OPUS encoder doesn't seem to understand long names. I moved the file into another folder with short path, the conversion worked.</p> <p>Error 3 & 4. The MOV file can be played by every player, even Windows Media player. Could consider an idea of checking procedure when adding files into list? In my opinion, LameXP should have shown a MessageBox that the file is unsupported.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/lordmulder"><img src="https://avatars.githubusercontent.com/u/470590?v=4" />lordmulder</a> commented <strong> 9 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>Error 1: It's just a JPEG file; it was embedded with TagScan and is seen by any player.</p> </blockquote> <p>"It's seen by any player" is <strong>not</strong> a prove for a 100% standard-compliant JPEG file. Players are made to deal with all kinds of messed up files that exist on the net. The check in <code>OpusEnc</code> might be more <em>strict</em>.</p> <p>Actually the JPEG detection code in OpusEnc looks like this:</p> <blockquote> <pre><code> int is_jpeg(const unsigned char *buf, size_t length){ return length>=11&&memcmp(buf,"\xFF\xD8\xFF\xE0",4)==0 &&(buf[4]<<8|buf[5])>=16&&memcmp(buf+6,"JFIF",5)==0; }</code></pre> </blockquote> <p>If you think the above code rejects some <em>legit</em> JPEG files, complain to the Opus guys, please ;-)</p> <p>Anyway, I implemented some changes, so that the MIME type is now passed to the <code>OpusEnc</code> explicitly: <a href="https://www.sendspace.com/file/9xdn1s"><strong>LameXP-BETA.2015-08-27.Release.Build-1795.zip</strong></a></p> <hr /> <blockquote> <p>Error 2: I don't delete files before conversion. My guess is that OPUS encoder doesn't seem to understand long names. I moved the file into another folder with short path, the conversion worked.</p> </blockquote> <p>Well, it could have happened by accident. But if you think that <code>OpusEnc</code> has problems dealing with long file names, then it would be another bug report directed to the Opus guys ;-)</p> <hr /> <blockquote> <p>Error 3 & 4. The MOV file can be played by every player, even Windows Media player. Could consider an idea of checking procedure when adding files into list? In my opinion, LameXP should have shown a MessageBox that the file is unsupported.</p> </blockquote> <p>MP4/MOV <strong>is</strong> supported by LameXP. Also <code>MediaInfo</code> apparently detects <em>this</em> file as MP4. Otherwise, LameXP would <em>reject</em> the file right away and show an error message. The actual problem here is that <code>MediaInfo</code> detects the file as MP4 and thus the file is <em>accepted</em>, but later <code>FAAD</code> fails to find an AAC audio stream in the file! Of course we can <strong>not</strong> try to decode <em>any</em> input file at the moment when it's added to the file list – just because there is the theoretical (but very unlikely) chance that decoding might fail later – because that would be <strong>way</strong> too slow. We have to trust MediaInfo on its findings at that point...</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/lordmulder"><img src="https://avatars.githubusercontent.com/u/470590?v=4" />lordmulder</a> commented <strong> 8 years ago</strong> </div> <div class="markdown-body"> <p>I'm going to consider this issue "done" for now.</p> </div> </div> <div class="page-bar-simple"> </div> <div class="footer"> <ul class="body"> <li>© <script> document.write(new Date().getFullYear()) </script> Githubissues.</li> <li>Githubissues is a development platform for aggregating issues.</li> </ul> </div> <script src="https://cdn.jsdelivr.net/npm/jquery@3.5.1/dist/jquery.min.js"></script> <script src="/githubissues/assets/js.js"></script> <script src="/githubissues/assets/markdown.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/highlight.min.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/languages/go.min.js"></script> <script> hljs.highlightAll(); </script> </body> </html>