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 9518 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

ACM / DirectShow for WavPack?

Reply #25 –
Quote
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.

Amen.

ACM / DirectShow for WavPack?

Reply #26 –
Quote
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.
Roger. One version of the SDK used FILE * as data source.. another one HANDL. both used char * as input file name.

Monkey Audio had the best API I've ever faced. One virtual reader interface and one decoding interface to be fed with data by the reader. This (IMHO I'm no container expert) should make the decoder able to receive data either from a file, network or a container. Adding unicode support is just a matter of overriding the constructor.
have the force, read the source
 

ACM / DirectShow for WavPack?

Reply #27 –
Quote
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.

Thanks, Peter. My current thinking is to have a new decoder open function that accepts two reader instances, one for the the main file and one for the correction file (which would be NULL if the application couldn't find it or can't be bothered). Not perfectly transparent, but much more usable. The encoder library interface was implemented this way.