| Summary: | media-plugins/audacious-plugins-1.3.5 - 33kb Windows PE executable in wavpack file causes misdetect | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Tobias Jakobi <liquid.acid> |
| Component: | Current packages | Assignee: | Tony Vroon (RETIRED) <chainsaw> |
| Status: | VERIFIED WONTFIX | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| URL: | http://bugs-meta.atheme-project.org/view.php?id=1038 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | wavpack chunck that doesn't play in audacious but everywhere else | ||
|
Description
Tobias Jakobi
2007-08-16 17:53:31 UTC
Please temporarily disable the Ogg/Vorbis decoder as it mistakenly picks up this files as one of its own. As MadPlug also picks this up, I have my doubts about these files. Please give me the output of file when run these "hybrid wavpack" files. We may need a sample file to confirm if the file output is not ambigous. OK, I disabled both madplug and the vorbis plugin. The hybrid-encoding still won't play. This time the log doesn't show anything and audacious only displays the "Unable to play files"-box. "Show more details" doesn't reveal anything. The normal wavpack (non-hybrid) now does playback and audacious also does seem to get the tags extracted. I check if I can extract a sample. Some notes about the hybrid encoding mode: It creates two files from the source audio. One with the .wv extension containing a lossy encoding of the source and another file with a .wvc extension, the correction file which contains the data to correct the audio. Wavpack playback also works when only the .wv file is present. The resulting audio obviously is only a lossy representation of the original. You only get lossless playback if also the .wvc is present. I tried to create a sample file filled with noise and encoded it with wavpack using hybrid. It plays back in audacious. So this won't work. Now I removed the .wvc from the lossless encoding in question. Still plays back in foobar2k (wine) and decodes (to lossy) with wvunpack. I upload a chunk from the beginning of the .wv file. This chunk should have no tags but plays fine in foobar (until it finds no more data) and also decodes in wvunpack (when ignoring the stored length information). Created attachment 128324 [details]
wavpack chunck that doesn't play in audacious but everywhere else
was ripped from the beginning of the file in question.
is a hybrid encoding, but here lacking the correction file
chainsaw@metis ~ $ file ~/Desktop/sample2.wv /home/chainsaw/Desktop/sample2.wv: MS-DOS executable PE for MS Windows (console) Intel 80386 32-bit, UPX compressed Playing /home/chainsaw/Desktop/sample2.wv. libavformat file format detected. [mp3 @ 0x105e1c54]Could not find codec parameters (Audio: mp3, 32 kb/s) LAVF_header: av_find_stream_info() failed This is not recognizable as audio to either file or mplayer. Please supply a sample that is. As I said it decodes fine with foobar2k and the reference wvunpack application. But indeed the file has a PE header: wine sample2.wv: WavPack Self-Extracting Hybrid Lossless Archive Version 4.40.0 Copyright (c) 1998 - 2006 Conifer Software. All Rights Reserved. I searched the wvpack homepage and the self-extraction feature is mentioned here: http://www.wavpack.com/wavpack_doc.html As this seems to be an official feature it should be supported by the decoders out there (and it IS obviously supported by wvunpack). Docs say: "It is possible to turn the .exe file back into a valid WavPack by simply changing the extension back to .wv (although the extra 33k unpacking header will still be there)." So this is a valid file. -e = create self-extracting executable (needs wvselfx.exe) Do not specify this option. We will not be rummaging through every windows executable on the disk to see if it just happened to be bolted to the front of a wavpack datastream. (In reply to comment #6) > As I said it decodes fine with foobar2k and the reference wvunpack application. > > But indeed the file has a PE header: > wine sample2.wv: > > WavPack Self-Extracting Hybrid Lossless Archive Version 4.40.0 > Copyright (c) 1998 - 2006 Conifer Software. All Rights Reserved. > > I searched the wvpack homepage and the self-extraction feature is mentioned > here: > http://www.wavpack.com/wavpack_doc.html > > As this seems to be an official feature it should be supported by the decoders > out there (and it IS obviously supported by wvunpack). > Docs say: > "It is possible to turn the .exe file back into a valid WavPack by simply > changing the extension back to .wv (although the extra 33k unpacking header > will still be there)." > > So this is a valid file. > The architecture of Audacious does not allow such things, and never will. Sorry. Oh, and I wrote the wavpack plugin. It will not ever support .exe based encapsulation. The answer is simply no, and I'm pretty sure Tony respects my opinion and won't cruft up my code with patches even if you do write one. I've read the docs by the time I posted them, so I know the switch ;) And it's not my encoding so the only thing I could do is to strip the header. Reported this upstream. And I doubt that you've to scan every .exe for wavpack data coming after a few bytes. The sfx code should be nearly identical for all these files and should be identified easily. (In reply to comment #9) > I've read the docs by the time I posted them, so I know the switch ;) > And it's not my encoding so the only thing I could do is to strip the header. > > Reported this upstream. > > And I doubt that you've to scan every .exe for wavpack data coming after a few > bytes. The sfx code should be nearly identical for all these files and should > be identified easily. > I am upstream, the lead developer of Audacious, AND the author of the wavpack plugin, and it will not be fixed. Please grow up and leave us alone. (In reply to comment #8) > The architecture of Audacious does not allow such things, and never will. > Sorry. > > Oh, and I wrote the wavpack plugin. It will not ever support .exe based > encapsulation. The answer is simply no, and I'm pretty sure Tony respects my > opinion and won't cruft up my code with patches even if you do write one. > Then why can I select 'detect file formats by extension' and it still won't work? I don't request that potential .exe wavpack file support should be added to audacious. But if the file has a .wv extension it should be possible to quickly check if this sfx header is there and to skip it. Or am I wrong? Is everybody mad at me now, or what? Hey I didn't mean provoke anyone here... @chainsaw: ..and never had the intention to 'bypass' you. But I'm really wondering why this would be a problem hard to fix. I mean when playing back mp3 with id3v2 tags you also have a lot of 'non-audio'-data in front of the mpeg stream (in case the id3v2 is not at the back of the file). For playing it back the app has to skip it. Now if this sfx code has a fixed size it should be easier than skipping id3v2, or not? (In reply to comment #12) > Now if this sfx code has a fixed size it should be easier than skipping id3v2, > or not? Can be broken as follows: 1) WavPack upstream releases a new extraction binary. Audacious skips into the audio stream wrongly and playback breaks. Other option: 2) Audacious tries to carefully look for the "WavPack Self-Extracting Hybrid Lossless Archive" in any Windows PE executable it finds. It gets horribly slow and everyone shouts at us. WavPack upstream changes the string and playback breaks anyway. Suggested option: 3) You do not try to pass off Windows PE executables as audio data and encode your files properly. (In reply to comment #11) > (In reply to comment #8) > > The architecture of Audacious does not allow such things, and never will. > > Sorry. > > > > Oh, and I wrote the wavpack plugin. It will not ever support .exe based > > encapsulation. The answer is simply no, and I'm pretty sure Tony respects my > > opinion and won't cruft up my code with patches even if you do write one. > > > > Then why can I select 'detect file formats by extension' and it still won't > work? > > I don't request that potential .exe wavpack file support should be added to > audacious. But if the file has a .wv extension it should be possible to quickly > check if this sfx header is there and to skip it. Or am I wrong? > Maybe you should read the documentation on what that feature does. It does not "skip" validation. The validation function of the plugin is what rejects your .exe. Stop bothering us, like I said. (In reply to comment #13) > Can be broken as follows: > 1) WavPack upstream releases a new extraction binary. Audacious skips into the > audio stream wrongly and playback breaks. > The real wavpack data seems to start at 0x8400h, a lot of zero bytes in front of it. As I don't know if that depends on the binary that created the file it would be best to ask the wavpack author. Maybe he already enforced a fixed size of this 'header'? That would make the whole thing trivial. > Other option: > 2) Audacious tries to carefully look for the "WavPack Self-Extracting Hybrid > Lossless Archive" in any Windows PE executable it finds. It gets horribly slow > and everyone shouts at us. WavPack upstream changes the string and playback > breaks anyway. > NO, that's not what I requested. It's totally clear to me that scanning each and every file for this 'header' and later wavpack data would kill performance of the app. This scanning (IF needed / header size variable) should only be done on files with .wv extension. > Suggested option: > 3) You do not try to pass off Windows PE executables as audio data and encode > your files properly. > I think about that :-) I'm going to write another mail to the wavpack author and ask him about this infernal header thing. (In reply to comment #12) > Is everybody mad at me now, or what? > > Hey I didn't mean provoke anyone here... > @chainsaw: ..and never had the intention to 'bypass' you. > > But I'm really wondering why this would be a problem hard to fix. I mean when > playing back mp3 with id3v2 tags you also have a lot of 'non-audio'-data in > front of the mpeg stream (in case the id3v2 is not at the back of the file). > For playing it back the app has to skip it. > Now if this sfx code has a fixed size it should be easier than skipping id3v2, > or not? > I'm going to be perfectly blunt here. Putting executable data in an audio format means that every time the executable data changes, *every single media player that supports the format must update their plugin or they will break when attempting to play the file*. Audacious will not, has not, and does not wish to fall prey to the "update the plugin when the format changes" mantra Wavpack appears to like so much. Go use Foobar2000 in Wine if it bothers you that much. (In reply to comment #16) > Putting executable data in an audio format means that every time the executable > data changes, *every single media player that supports the format must update > their plugin or they will break when attempting to play the file*. Audacious > will not, has not, and does not wish to fall prey to the "update the plugin > when the format changes" mantra Wavpack appears to like so much. > Maybe the author has always used the same offset for storing the real wavpack data? We don't know that for sure. Or the offset is stored/encoded inside the PE. So I would only be a check for PE, if found the offset is fetched and the junk skipped. Again I don't know this so I wait for the wvpack author to write me back. > Go use Foobar2000 in Wine if it bothers you that much. > Actually I'm trying to use it less often. Audacious is a great media player and I not only saying this to soothe nenolod ;) David Bryant wrote me back: Hi Tobias, Unfortunately, the size of the pre-pended self-extraction header has changed in the past, and could very well change in the future. However, it really shouldn't matter because the WavPack library automatically skips any garbage before (or between) WavPack blocks. The problem on Linux is that it seems more common that programs will ignore the extension of files and instead rely on identifying them by looking at the first few bytes. This is the problem with Audacious; it chooses the codec based on the first few bytes and never even gets to the WavPack decoder. Stripping off the self-extraction header will obviously work fine, but I think there are a couple of much easier solutions. I took a WavPack file with the self-extraction header and pre-pended (using cat) the 4 bytes 'wvpk' to the beginning and Audacious played it fine (Audacious is what I use on Linux). Unfortunately, this involves rewriting the whole file but it's also possible to *replace* the first 4 bytes of the file with 'wvpk' and I'm pretty sure this would work too (but it would require a hex file editor which I don't have handy). The reason this works is that Audacious sees the 'wvpk' at the beginning and so calls the WavPack decoder which ignores the 'wvpk' because what follows is not a valid header and so searches ahead and finds the real header. Viola! This should work in most situations. The only situation I can imagine it not working is when a program tries to go into the first header to find more information like sampling rate or duration (which they really shouldn't be doing). As long as they use the library it should be find. The response you got on that thread is a little strident, but it's their program so they can do as they like. That last response was a little off though because even if I change the self-extraction header there's no reason for anybody to change the plugin because the WavPack library handles the whole thing. And then he makes a comment implying that WavPack likes to do this often. I think he may be confusing WavPack with FLAC because FLAC recently changed their API and made everybody adapt and I think that's why Audacious looked at WavPack in the first place! Anyway, I hope this solves your problem and thanks for letting me know about it (and for using WavPack). Regards, David (quote end) ------------------ So it seems this problem isn't so easily to fix or avoid. I try to write some small script that strips the EXE from the from by finding the first valid wavpack header in the file. This way I won't have to recompress the file. |
