Anyone interested in doing a few odd-jobs?

[Leirbag]

As I suggested time ago, VST3 could be a good idea for Juce libraries. My vote for their implementation.

[Happy]

hi Jules,

Can u post the completion of modules when it is done. we might be trying to implement when its already completed.

Regards,
Happy

[Happy]

- A CoreCodecAudioFormat class that can open and read (but not necessarily write) audio files using CoreCodec.
- A DirectShowAudioFormat class.. same as above, but for Windows.

open and read from which audio format?? JUCE already has audioformat to read and write to file.

[jules]

Can u post the completion of modules when it is done. we might be trying to implement when its already completed

Please don't start on anything without asking me! If you're interested, contact me directly to discuss it.

open and read from which audio format??

well, for any format that the OS provides a codec for. Juce provides built-in support for a few open formats, but I haven't added things like mp3, AAC etc, because of patent issues.

[Happy]

hi Jules,

I m interested in creating DirectShowAudioFormat class. Can u please provide me the specification at sandy4coding@gmail.com

Regards,
Sandy.

[chkn]

It seems that the ability to decode MP3 with DirectShow is somehow limited, on certain Windows versions, correct me if i'm wrong. I've done 2 days of research but i found nothing really substantial. But i checked also the old Windows ACM architecture, and it works on Windows Vista and Windows 7, which is i think a good sign! (Jules i send you some files)

[sonic59]

Windows ACM is a legacy API from the Windows 3.1 days. It should be left for dead along with VfW.

Ideally, the Windows Audio Format class should be written using Media Foundation and not DirectShow. DirectShow is deprecated and some of the newest encoders/decoders only work with Media Foundation. The only downside is no XP support.

Media Foundation supported codecs: WMA, AAC (Win7 Only)
Media Foundation supported decoders: MP3, μ-law, ADPCM, GSM 6.10
http://msdn.microsoft.com/en-us/library ... 85%29.aspx

DirectShow supported codecs: WMA, WM Speech
DirectShow supported decoders: MP3, WMAPro
http://blogs.msdn.com/b/matthew_van_eer ... ystem.aspx

[chkn]

oh thats interesting, would be nice to know if that really works on Windows 7 and Vista for MP3 decoding (in practice), are there working examples somewhere?
I somewhere read that the mp3 DirectShow filters are somehow deactivated when using it in third-Party apps in the newer Windows versions. ( And i never found a example after intesive research)
Anyway, the ACM api seems to work, even if they are legacy, the most important thing to have a working solution for mp3 import.

[dinaiz]

Anyway, the ACM api seems to work, even if they are legacy, the most important thing to have a working solution for mp3 import.

Amen

[sonic59]

Media Foundation sample code can be found here:
http://msdn.microsoft.com/en-us/library ... 85%29.aspx

[chkn]

ok, it seems that the examples are not compatible with the SDK of VS2008 (v6.0a), so can someone compile the audioclip example, and see if its possible to convert a mp3 file to wav pcm, please?

[sonic59]

Compiles fine in VS2010. Both MP3 and AAC decoding are working fine using AudioClip on Windows 7.

[drand48]

Hi,
regarding a openGL/GLES backend I came across this lib today by google, seems interesting!
http://code.google.com/p/skia/
haven't looked much into it but maybe a SkiaRenderer could work?

[jules]

Hi,
regarding a openGL/GLES backend I came across this lib today by google, seems interesting!
http://code.google.com/p/skia/
haven't looked much into it but maybe a SkiaRenderer could work?

It's the engine that they use in android, isn't it? Could be interesting, but I'm really after a solution without all the baggage, i.e. just a one-file solution that renders a juce graphics context via GL calls without any external dependencies.

[pwhittemore]

Since it seems that LAME is one of the better encoders and decoders, and is not patent-encumbered for application use if the end-user installs it, I'd really like to see support for an optional loading and use of LAME if the end-user has installed it, otherwise just return an error, etc. It's a cross-platform way for JUCE to include support for MP3 encoding and decoding without running afoul of the patent restrictions. There would actually not be any MP3 code in JUCE, just support for use of an optionally-installed third-party library...

This is the way I planned to support MP3 decoding and encoding (which I need in my project). It's been postponed due to my core work and other priorities, but that work has ended now and I'm finally renewing my interest in this project. I was hoping that someone else would have already gotten to this, but I will do this work if no one else does before I need it.

Given JUCE's orientation towards audio, I find it very surprising we've come this far without more support for MP3s. Yeah, I know... it's all the stinkin' patent's fault, but I think this end-user installed approach works well. It's the approach that SAM Broadcaster uses to provide optional LAME encoding:
http://www.fastserv.com/kb/article/using_lame_acm_codec_with_spacial_audio_sam_broadcaster/
There's a good discussion of using LAME as an alternative encoder in other apps here.

And LAME is available for all platforms, so it's got great bang-for-the-buck potential in terms of the benefit of writing a JUCE encoder/decoder wrapper around it.