Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: ACM / DirectShow for WavPack? (Read 9439 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

ACM / DirectShow for WavPack?

Are there any plans to create either a DirectShow (DirectSound, DirectX, whatever you want to call it) filter for encoding/decoding WavPack files?

The older ACM architecture was apparently limited to CBR, that would tie in nicely with the "lossy" feature available with WavPack. Only thing is, ACM is now a bit outdated - although many programs still do use it.

I was of the understanding that ACM could only do CBR, but an ACM was released for FLAC*  , although I could not get it to work 

(*As many of you would know, FLAC is VBR, so this was a bit of a surprise)

ACM / DirectShow for WavPack?

Reply #1
You could try contacting the RadLight team, they have been releasing several audio directshow filters lately: Monkey's Audio, MusePack, OptimFrog, TTA...

ACM / DirectShow for WavPack?

Reply #2
We are currently working on adding TTA and WavPack support in Matroska. TTA is almost done because it's easier than WavPack (no hybrid mode). Toff already has a DirectShow filter to support TTA in Matroska and we have tools to put TTA in Matroska.

The same will follow soon with WavPack (expect it in less than 2 weeks). And hopefully both filters will support TTA/WavPack inside Matroska and in their original form.

So just be patient and things will come.

ACM / DirectShow for WavPack?

Reply #3
Don't want to offend anyone but the WavPack code sucks. Big mess.

ACM / DirectShow for WavPack?

Reply #4
Quote
Don't want to offend anyone but the WavPack code sucks. Big mess.

And how much not offending do you think this is ? 

ACM / DirectShow for WavPack?

Reply #5
Quote
Don't want to offend anyone but the WavPack code sucks. Big mess.

I really dont want to start a flame war, but

- we loved to be scared by the high quality of your code, but unfortunately you guys constantly forget to release your sources for your splendid DirectShow filters ? For musepack this is even legal, because the decoder is L-GPL, but still questionairy IMO, with respect to the open community you are posting to here. However, for TTA its simply a complete disrespecting of the GPL licensing agreement. And no, its not enough to send the sources to the TTA developer Alexander, if you publish binaries for download on your server, you have to give PUBLIC access to the sources also, the GPL is clearly stating this.

- its the quality of all your splendid DirectShow filters that sucks, they are very very simple and basic source filters, any experienced coder can make those in less than 2 hours, especially if the skeleton of such a source filter was done once already. A source filter to read and decode one format only is completely against the idea of a framework like DirectShow, in fact M$ recommends to make those as DMOs only, and not as real filters, to avoid complications in the graph building.
Needless to say that they dont allow to use the respective audio format from any other container than their basic framing, and this well includes other flexible containers like MP4 and even Ogg, not only matroska. The reason why we never converted our complete range of TCMP audio decoder filters into DMOs for WMP was exactly for that reason, we wnated to avoid that such simple source filters get widely spread, and may compromise a superior solution with a clean architecture, i.e. a real parser filter for the framing and separated decoder filters.

Of course, you guys dont give a dime for that, your intentions are very obvious to anybody who has been in the scene long enough  .....

ACM / DirectShow for WavPack?

Reply #6
Quote
but still questionairy IMO, with respect to the open community you are posting to here.

"open community" my @$$. Up to a couple of months ago MPC was a closed format, and noone ever complained it conflicted with this "open community". Also, both recomended AAC encoders are closed, and nobody complained except for the lack of a Linux version. Same thing about Monkey's Audio.

Quote
And no, its not enough to send the sources to the TTA developer Alexander, if you publish binaries for download on your server, you have to give PUBLIC access to the sources also, the GPL is clearly stating this.


I can see you never even bothered to read the GPL (or, if you read, it was too complex for you to understand). The GPL doesn't state that if you put the binaries at a web server, you must put the sources at the same server.

So, yes, sending them to someone else to host is perfectly fine and acceptable, as long as you link to them at the same place you link the binaries.

I personally host loads of GPLd binaries at RareWares (specially at the debian repository), and only a handful of source files (only in the case these sources had been modified for the RW release).

<anal-gnuish-mode>
The FSF actually recommends the primary means of source code distribution to be through mail order, and not internet-based (e-mail, FTP, web). The reason is that mail order pretty much guarantees access to anyone. internet-based limits access to people with internet access.
</anal-gnuish-mode>

The GNU interpretation on this matter:
http://www.gnu.org/licenses/gpl-faq.html#S...nDifferentSites

Quote
Of course, you guys dont give a dime for that, your intentions are very obvious to anybody who has been in the scene long enough  .....


OMG! A hidden evil agenda.

And I hope they fullfill these intentions, if they are the ones I'm guessing

ACM / DirectShow for WavPack?

Reply #7
Quote
Quote
Don't want to offend anyone but the WavPack code sucks. Big mess.

And how much not offending do you think this is ? 

Well, not being able to get it to compile after 2 hours of trying can make you feel really mad. 

The fact is I don't have anything against WavPack "the lossless encoder" but rather against WavPack "the implementation" (just look at OptimFROG, it has really nice SDK and everything).

This makes it difficult for us and forces us to do all kind of hacking just to get UNICODE to work and allow opening of STREAMS, not only FILE INPUT.

P.S RadScorpion is rather the calm type but this time we almost lost our office furniture 

ACM / DirectShow for WavPack?

Reply #8
Quote
And no, its not enough to send the sources to the TTA developer Alexander, if you publish binaries for download on your server, you have to give PUBLIC access to the sources also, the GPL is clearly stating this.

On the other hand the original developer has copyright to his code and he can license it under different conditions. It is completely legal to allow some proprietary implemantations to use your stuff without releasing sources if you have the copyright on our own code.

ACM / DirectShow for WavPack?

Reply #9
Quote
On the other hand the original developer has copyright to his code and he can license it under different conditions. It is completely legal to allow some proprietary implemantations to use your stuff without releasing sources if you have the copyright on our own code.

Excellent point. Given that Alexander is hosting the RadLight filter and sources, it means he accepts that arrangement, even if it didn't comply completely with the GPL (it does).

Ultimately, the copyright holder is the one to seek legal action against parties breaking his license. If Alexander isn't seeking it, it's not up to ChristianHJW, CoreCodec or whoever believe he/she/it has the right to do so.

ACM / DirectShow for WavPack?

Reply #10
The picture is not as simple as you make it.

TTA was hosted on CoreCodec before it got down (and will eventually be back). We have been in contact with them since them to integrate it in Matroska and make a decent DirectShow implementation. Which is almost done, but we don't publish stuff that is only half done.

Then comes RadLight who makes the simplest possible implementation and don't even publish the sources. So we were a bit worried that our efforts to make something clean are made almost useless because someone else take the easy/dirty path.

I knew RadLight had a bad reputation, but never really understood until now. You can also check the matroska-dev ML for more fun.

And now they claim WavPack's code is dirty. While I personally have never had a problem compiling it on Windows and had minimum work to do to make it work on Linux and OS X. (see other thread) So this claim of dirty code is just arrogant bullshit. But don't worry. You won't need to wait for RadLight to have a DirectShow filter that works for normal/hybrid mode in native and Matroska formats.

ACM / DirectShow for WavPack?

Reply #11
Quote
Then comes RadLight who makes the simplest possible implementation and don't even publish the sources. So we were a bit worried that our efforts to make something clean are made almost useless because someone else take the easy/dirty path.

If your implementation is better than theirs, it'll eventually replace it. It doesn't justify whining as a spoiled brat about RadLight releasing their app first. It works for what people want now (playback of TTA files on DShow applications), so it can't be that bad, at least from an end-user point of view.

Also, if you want to take out the RadLight team in purely technical terms, do so. But don't put Christian to discuss something he obviously doesn't know anything about.

Quote
I knew RadLight had a bad reputation, but never really understood until now. You can also check the matroska-dev ML for more fun.


What? Dan Marlin making more hollow threats in an attempt to ruin someone else's shit? No, I got plenty of hints how unethical and childish you guys can be.

Someone please split this thread. Starting at DAvenger's first post would probably be a good idea.

 

ACM / DirectShow for WavPack?

Reply #13
Quote
Someone please split this thread.


I would suggest closing it too. Once again, I am sorry for making that stupid comment (I usually don't do that - guess I really need that vacation  ) which gave them a good starting point to hijack this thread. 

ACM / DirectShow for WavPack?

Reply #14
Quote
I accept the word childish, but not unethical. So please give a bit more baking to what you are claiming.

If you don't agree that Dan Marlin trying to mess a deal he has no business with (although they are his competition), by threatening to put Tobias in sour relations with Xiph through IRC logs, is not unethical, then nothing can be.

Quote
(or maybe should I be sorry to have forced RadLight to publish their source which they probably had no itention to do ?)


That just showed you meddled in subjects you have no business with. It's up to the TTA developers to enforce the licensing or not, no matter if you are a format enthusiast, and anti-RadLight zealot or just a guy with too much free time.

ACM / DirectShow for WavPack?

Reply #15
Quote
It's up to the TTA developers to enforce the licensing or not


This makes it sound like if there was something wrong with what we did. 

My comments to Steve (that's your name, right?), don't make me post what I am going to post if you don't stop with this nonsense. I am afraid that nobody would ever take you seriously after that.

ACM / DirectShow for WavPack?

Reply #16
Quote
The older ACM architecture was apparently limited to CBR, that would tie in nicely with the "lossy" feature available with WavPack. Only thing is, ACM is now a bit outdated - although many programs still do use it.

I was of the understanding that ACM could only do CBR, but an ACM was released for FLAC*   , although I could not get it to work 

(*As many of you would know, FLAC is VBR, so this was a bit of a surprise)

I to admit that the FLAC ACM was a rather kludgey hack. My main hope was that it would be usefully to open/save .flac with a wav header attached for music editing. As Sound Forge always decompressed the wav when opening it seemed to work well.
For use outside of wav it wouldn't work, freeze/crash.

An ACM should be possible if the lossy mode of WavPack is CBR as mp3 is, constant frame sizes.
I still have the FLAC ACM source code so I have a starting code base. Just need a library version of WavPack.

ACM / DirectShow for WavPack?

Reply #17
Quote
Quote
(or maybe should I be sorry to have forced RadLight to publish their source which they probably had no itention to do ?)


That just showed you meddled in subjects you have no business with. It's up to the TTA developers to enforce the licensing or not, no matter if you are a format enthusiast, and anti-RadLight zealot or just a guy with too much free time.

That's where you are wrong !

And you poped up with the very precise subject that shows you are wrong : OGM !

OGM was based on open source technology but with a closed source implementation that only one person could understand. People (Cyrius and Mosu) had to reverse engineer that supposedly open/patent-free technology to make tools to use it. And we (Matroska/CoreCodec) fought as much as we could to have OGM be more open, even though we are not part of it (well, Cyrius and Mosu both work on Matroska from the start) and it's competing what we have created. Because we CARE. This is the exact same thing with TTA and all other technology we are interrested into.

OGM had some bugs that led us to make CoreVorbis, because Vorbis wouldn't work well in Matroska with the original filters we couldn't modify. The very same could happen with TTA and closed filters.

It's not because we are developers of other solutions that we have no right to shout when we disagree !

(so far OGM is still undocumented even though the sources are public)

ACM / DirectShow for WavPack?

Reply #18
When you shout on your own just because you "disagree", you risk making a huge fool out of yourself. What if the TTA developers had accepted already that the RadLight team doesn't release the sources? What if they didn't care?

If you have no authority over the subject, you should just stay put.

ACM / DirectShow for WavPack?

Reply #19
Quote
What if the TTA developers had accepted already that the RadLight team doesn't release the sources? What if they didn't care?

If you have no authority over the subject, you should just stay put.

The OGM sources wouldn't be on Xiph website if everybody were thinking like you do (and some things would have never been fixed). The fact that it's legal is not even important here. Because in the case of OGM it was completely legal not to release the sources. Which doesn't mean it's a good thing.

Everyone taking some open source code, using it and keeping the changes/additions for himself should always be prepared to such rants. That's part of the deal IMO. And hopefully it will stay this way and even grow.

ACM / DirectShow for WavPack?

Reply #20
Back on topic. After I did the LAME ACM, I planned to make ACM versions of all popular codecs (FAAC, FLAC, MPC). But I quickly stop when I saw the problems with MP3. ACM is simply not a good solution to mix audio with video. The VBR nature of most codec make it impossible to work without being hacky (misintrepreting the specs). And in the end it doesn't work well enough. So I wouldn't advise anyone to create ACM for VBR content. Because you're taking a route that will lead to problematic files in the end.

In the other hand DirectShow is fine for that. Even though a bit complex to make simple things.

ACM / DirectShow for WavPack?

Reply #21
Quote
The OGM sources wouldn't be on Xiph website if everybody were thinking like you do

And did it make any difference? The impression I have is that one of the reasons Tobias stopped working on it was because of stubborn whiners demanding him to open sources and release specs. So now you got deprecated old sources that noone is interested in working on. You surely prefer to see OGM dead, but I prefered the time the sources were closed, but at least there was someone working on them.

Quote
Everyone taking some open source code, using it and keeping the changes/additions for himself should always be prepared to such rants. That's part of the deal IMO. And hopefully it will stay this way and even grow.


Yes, as long as the amount of opinionated and thickskulled people keeps growing...

ACM / DirectShow for WavPack?

Reply #22
Quote
Quote
The OGM sources wouldn't be on Xiph website if everybody were thinking like you do

And did it make any difference? The impression I have is that one of the reasons Tobias stopped working on it was because of stubborn whiners demanding him to open sources and release specs. So now you got deprecated old sources that noone is interested in working on.

Of course it made a difference ! From the moment the sources were released about 5 major bugs were corrected (by Koepi) and some new features were added (more sub formats IIRC). Asking for the sources was not just for political matters and to annoy Tobias, but for technical reasons too. And nobody ever understood why Tobias wouldn't release the sources (dirty code is not an excuse).

Do I prefer OGM dead ? Personally yes. But I wonder if Xiph are thinking differently...

ACM / DirectShow for WavPack?

Reply #23
Quote
Quote
Quote
Don't want to offend anyone but the WavPack code sucks. Big mess.

And how much not offending do you think this is ? 

Well, not being able to get it to compile after 2 hours of trying can make you feel really mad. 

The fact is I don't have anything against WavPack "the lossless encoder" but rather against WavPack "the implementation" (just look at OptimFROG, it has really nice SDK and everything).

This makes it difficult for us and forces us to do all kind of hacking just to get UNICODE to work and allow opening of STREAMS, not only FILE INPUT.

P.S RadScorpion is rather the calm type but this time we almost lost our office furniture 

I wasn't going to respond to this, but since I've thought about it and this thread keeps coming up, I would like to say something (without offending anyone, of course).

There are two points I'd like to make. Now I don't know exactly when this two hour, furniture endangering episode occurred (I moved to streams with 4.0), but why couldn't this have prompted a friendly e-mail (hopefully after blood pressure levels were back to normal)? There is actually a pattern here. Despite the fact that thousands of people have downloaded the WavPack sources over the years, I have never, not once, received an e-mail saying "Hey, I want to do X with your code and I can't because of Y. Have you considered doing Z?". Instead I hear suggestions through backhanded insults on forums. Very helpful.

The fact is that my background is embedded systems and my native tongue fits very nicely in 94 ASCII characters, so unfortunately I am slower than most to pick up on UTF-8 and UNICODE, and I am actually proud of myself when I can make a dialog box work right. I have been concentrating on making the WavPack 4.0 format as efficient, robust and flexible as possible (with hardware decoding in mind), and am hoping that since it's completely open I might get some help on the areas that I don't have time to become expert in.

Now, specifically with respect to the comparison to OptimFROG's SDK. I think OptimFROG is a great compressor (much better than WavPack in an academic sense) with a nice SDK. And, interestingly, Florin is the only person on this forum that I have actually met in person. But I don't think a direct comparison with WavPack's library is totally fair. First off, since OptimFROG is not open source, the SDK had better perform (flawlessly) all the functions required by a developer or he'll just be SOL. Since the source of WavPack's library is freely available (and the license allows basically anything), it is possible for a developer to hack in any functionality or characteristic that they might need, and maybe even improve it in the process. If they are just too good to do that, then I guess I'm the one who's SOL. 

There's also a question of functionality. The last time I checked, OptimFROG's plugins and library do not decode the "correction" file. This is how WavPack's hybrid mode worked initially, and I got beaten up for it and now I agree that if the correction file is available then it should be used in all cases (unless the user specifically disables it). It's a little hard to argue that the two files are as good as one lossless file when they don't work the same. This is an enormous complication and requires (if it's to be done transparently) that the filename be passed to the decoder so that the decoder can attempt to open and read any correction file. I don't like this (and I'll probably come up with something else somewhat less transparent), but this is functionality that I really don't want to just give up on. Also along the lines of functionality, the latest WavPack library and plugins also support floating point data and multichannel audio. And now there's a encoding library too; and if it doesn't do exactly what you want, ask! I don't bite.

As for the DirectShow filter, I'll leave that to robUx4 and the gang (who have been great and actually do e-mail me). If, for some reason, they are unable to come through, I'll take a look at that TTA implementation for some pointers. Thanks for making it available... 

ACM / DirectShow for WavPack?

Reply #24
Quote
The fact is that my background is embedded systems and my native tongue fits very nicely in 94 ASCII characters, so unfortunately I am slower than most to pick up on UTF-8 and UNICODE, and I am actually proud of myself when I can make a dialog box work right. I have been concentrating on making the WavPack 4.0 format as efficient, robust and flexible as possible (with hardware decoding in mind), and am hoping that since it's completely open I might get some help on the areas that I don't have time to become expert in.

You don't need to learn or understand unicode/UTF-8 to make your library not interfere with it. Just implement file I/O callback mechanisms instead of making your library take a char* filename. If you think that's problematic, provide alternate file open function that takes file path and uses its own standard implementation of the callback, just like libvorbis does. That's currently biggest issue with your code (as far as I've read into it) because making a non-broken DirectShow filter or foobar2000 component requires severe changes in your source, and not many people have time to do that (especially that your library may need updating later, so hacking would need to be re-applied). Implementing file I/O callback involves changes that are too big to for someone to just make them and send you a patch, since you should be the one who makes architectural/design decisions there.
Microsoft Windows: We can't script here, this is bat country.