I have searched high and low, and cannot find any decent MP3 decoders =/
I need one that will compile under gcc/linux.
The closest thing i could find was libmad, which has no documentation at all, and the only example I could find was the one on their home page, which is really complicated.
Does anyone know where I can find one?
I have used MAD (MPEG Audio Decoder) in the past with great results, so I would not give up on it so quickly. MAD is specialy designed for good performance on CPUs without floating-point operations, which is desirable while developing applications for mobile devices for example. I would like to recommend you to take a look on the source code of this project (GSPlayer). It is an audio player for Windows CE/Windows Mobile and it uses libmad. The code is fully functional, neat, and not too large, so it may help you to get an idea on how to use libmad on your own projects.
You may have to verify the license (GPL) for libmad though, since it may not suit your needs.
Have you looked at Lame?
Looking at its command-line page, I can see at least a few options that look promising, such as --decode and --mp3input. That would hint that the underlying library has the ability to do what you need, I would imagine. Whether or not it has nice, well-encapsulated C++ functions for decoding mp3s is another story.
As correctly noted in the comments, you should carefully examine the licensing and patent agreements.
ffmpeg should be able to handle MP3s without difficulty. How easy it is to actually access that functionality though, I cannot say.
have a look at this application, very easy to use,
programmed in C and works on windows/linux
http://sourceforge.net/projects/mp3decoder/
Related
I'm trying to read MXF files (from Avid) into an Objective-C project and analyze some frames from video. Preferably getting them into a CGImage or NSImage.
I've been exploring the mxflib, but find myself at a bit of a standstill. I'm used to the mechanics of the standard video methods within Obj-c, but this package is C++ and not exactly something I'm familiar with.
Does anyone have experience working with this library or another similar one? There's not much information available on the subject (at least not that I can understand). And I'm not quite sure where to begin.
Actually, I'd say you're looking at it from a not so good way, as the mxflib is prepared to handle standard MXF files, not really Avid ones.
In short, for this to work, you need to extend the library as per Avid specs (it can be done!) or go with AMT, for which I understand you need to engage Avid to have it.
Finally, I think you're stuck with C++! ;-)
We have some researchers who do a lot of work in MATLAB. We often would love to try their code as part of a bigger workflow that requies the algorithms to be put into C/C++ or Python. I've seen MathWorks advertise a tool to create native C or C++ code. How good is the code? Does it support the toolboxes? I'd still see it as an early prototyping tool but wondering how good the code is. Thoughts?
I have worked with mathworks extensively in the past on this. The toolboxes are expensive, but the support is outstanding. We benchmarked code generated for a specific DSP and it was within 10% the speed of hand generated code, and took a fraction of the time to generate. Mathworks has been investing heavily in these toolchains the past several years and they are getting very good. Some toolboxes are supported, look at the docs online.
The code produced by the Embedded Coder is, in my opinion, very good and it's a product that is widely used in industry, especially in automotive applications. It's generally designed to generate code from Simulink for real-time applications though. Look at the user stories on the website: http://www.mathworks.co.uk/products/embedded-coder/?s_cid=global_nav.
Support for toolboxes depends on what your requirements are. If you need something that only uses standard libraries, then support is limited, but if that doesn't matter to you, then you may have more success.
A word of warning though: it's expensive.
I know that a lot of c/c++ XML library questions have been asked already (I tried to read through all of them before getting to this).
Here are the things I'm going to need in my own project:
Excellent performance
SAX2
Validation
Open source
Cross platform
I was going to use Xerces-C, but I see that a simple SAX2 setup with nothing going on in the filter is taking 5 seconds to run. (Perhaps I'm doing something wrong here?)
I would like to use libxml++, but as I tried to get it set up on my MacBook, there were some crazy dependencies that took me all the way back to gtk-doc, at which point I sort of tabled the idea.
So now I'm at libxml2. Is this the way to go? Have I missed an important option, bearing in mind the five requirements above? I don't mind using a (good) c-library like libxml2, but a c++ interface would be nice. (I don't like Xerces-C's API very much.)
I am willing to bend on the SAX2 requirement if comparable functionality is available.
Having spent a goodly amount of time on this same problem, it was my conclusion that libxml2 is the best option available under your guidelines. The C interface is not too difficult to use and it's very fast.
There are some other good options for commercial libraries, but most of the other comparable open-source options are either painfully slow or are mired in a deep, annoying vat of dependency soup.
You say you need these things in your project, but don't give any idea of the pipeline. For example, we had a whole load of static XML files which needed to be loaded quickly, but only validated rarely. So validated using a separate process in batch (using RelaxNG as it was human writable markup ) and loaded the XML using expat. The system also used XMPP, so checked streaming input, but that didn't require validating against a schema (partly because it was streamed, and mostly because most of the possible errors were not expressible in a schema).
If you need a whole host of other facilities, you can consider Qt, which has good XML support. Be warned though, it's WAY more than an XML processing library; it's a full blown application framework with support for GUIs, networking and a whole host of other things.
Qt
You can also try Poco. It's another application framework, but not as huge as Qt (i.e. no GUI-related things etc.)
Poco
Lastly, if you don't mind a C library, you can use Expat. It's not SAX per se, but writing code using Expat is somewhat like SAX. It has C++ wrappers, but they're not officially part of the project IIRC, and may not be as well-maintained or designed. I'm not too sure though.
Expat
Hope this helps!
EDIT: I misread your original post: not too sure about the validation features of these libraries, I've never used them before.
I'm looking to add full text indexing to a Linux desktop application written in C++. I am thinking that the easiest way to do this would be to call an existing library or utility. This article reviews various open source utilities available for the Gnome and KDE desktops; metatracker, recoll and stigi are all written in C++ so they each seem reasonable. But I cannot find any notable documentation on how to use them as libraries or through an API. I could, instead, use something like Clucene or Xapian, which are generic full text indexing libraries. They seem more straightforward but if I used them, I'd have to implement my own indexing daemon, an unappealing prospect.
Also, Xesam seems to be the latest thing, does anyone have any evidence that it works?
So, does anyone have experience using any of the applications or libraries? How did you use it and what documentation was useful?
I used CLucene, which you mentioned (and also Lucene.NET), and found it to be pretty good.
There's also Strigi which AFAIK works with Xesam and is the default used in KDE.
After further looking around, I found and worked with Recol. It believe that it has the best C++ interface to a full text search engine, in this case Xapian.
It is important to realize that clucene and Xapian are both highly complex libraries designed primarily for multi-user server applications. Cutting them down to a level appropriate for a client-system is not easy. If I remember correctly, Strigi has a complex, pure C interface which isn't adapted.
Clucene also doesn't seem to be that actively maintained currently and Xapian seems to be maintained. But the thing is the existence of recol, which allows you to index particular files without the massive, massive setup that raw Xapian or clucene requires - creating your own "stemming" set is not normally desirable, etc.
I am going to start a game in about 3 weeks and I would really like the game to run at least on another platform (linux, MacOS) but my team thinks that's a lot of work. I am up for it but wanted to know what are the things I should watch out for that won't port to linux (apart from Windows specific APIs like DirectXsound)?
I've been reading online and Windows "_s" functions like sprintf_s appear to exist only on Windows; is this correct or are they implemented on linux also?
No, the _s functions are NOT implemented in the standard gcc library.
(At least, grepping the include files for 'sprintf_s' turns up nothing at all.)
It might be worth looking at cross platform libraries like boost and apr to do some of the heavy lifting work.
A sample of specific things to look for:
Input/Output (DirectX / SDL / OpenGL)
Win32/windows.h functionality (CreateThread, etc)
Using windows controls on the UI
Synchronization primitives (critical sections, events)
Filepaths (directory separators, root names)
Wide char implementations (16 bit on windows, 32bit on linux)
No MFC support on linux (CString, etc)
If I were you I would use some of the available Frameworks out there, that handle Platform independence.
I wrote a 3D-Game as a hobby project with a friend of mine, the server being in Java and the clients running on Windows and Linux. We ended up using Ogre as 3D-Engine and OpenAL as Sound-Engine, both platform independent and available under LGPL.
The only things I really had to write separately were the whole Socket-handling, reading the config from file system and the initialization of the System. Compared to the rest of the Program, that was almost nothing.
The most time consuming will be to set up the entire project to compile under Windows and Linux (or Mac), especially if you're concentrating on one and only occasionally check the other for problems. If you have one in your team who checks regularly for these problems while they're being produced you won't have that much overhead from that as well.
All in all compared to the programming of the game itself, adapting it to different platforms is almost no effort, if all frameworks used are well written, platform independent systems.
Try to encapsulate any non-standard extentions like DirectX, OpenGL, SDL, etc. Then you only have to rewrite those parts based on platform.
I also would make it playable on one OS before even thinking of porting.
For the 'safe' functions: they are non-standard, and almost safe :)
Endianess is something look out for.
Endianess is the order of the bits in a byte. Some platforms are big endian while some are little endian.
This can affect how cross-platform your program is. But the biggest impact this would have would be in network communications. You have to convert from one endian to another before sending or receiving a network message.
If you focus on gameplay, design a game, and them implement that porting should not be especially onerous. If you implement it simultaneous on several platforms it should be straight forward.
But if you focus on effects, design something that you feel is going to "blow the others out of the water," and try to paste a game idea onto them, you are doomed.
So really it is up to you.
Don't know much about windows-apis, but I set up a daily (or on-commit) fully automatic build-system on all platforms you want to support. If you develop something on your windows-box that doesn't work on the others, your build-system should notify you of "failed build on platform x, see logfile/attachment/whatnot for details". It'll catch a lot of cross-paltform issues. Unittests will help as well.
Whether or not to target multiple platforms from the start is a good idea is another question.
Personally I'd start developing on another platform and then see about porting it to windows at a later time ;-)
Just remember that you are creating a model of game that does not depend on the details of any operating system. Your game depends on state management and algorithms which don't depend on the OS. The key is to write your game logic without dependencies to specific libraries which means a lot of encapsulation.
You shouldn't call sprintf_s directly you should write an routine, class, or MACRO that can be changed based on the platform, Don't use DWORD when you can use a class or typedef that can be tailored to different platforms.
For instance if you where making a football game, then algorithms for throwing the ball, running, tackling, positions of the players could be done completely in standard C++ without platform dependencies. If your encapsulation was good you could dump the state of you game to a file and display it separately with a rendering program.
If you truly want to do cross platform development easily I would suggest using one of the already built cross-platform engines like Unity or one of the Garage Games stuff like Torque Game Builder (2D).
I have virtually zero experience in either so can't tell you which is better but the Torque Game builder demo couldn't get through the first tutorial without having problems and they don't answer tech support questions in their forums like they claim to do so I can say avoid them if you are a novice in game design like myself. The big thing about Garage Games was supposed to be their great support, I saw zero support and in fact only saw a bunch of, "Hey, anybody here?" posts with no answers so I guess they are pretty much giving up on supporting their products.
http://unity3d.com/
http://www.garagegames.com/
I'm surprised nobody mentions libSDL and OpenGL because most cross platform games were written using those libraries.
If your game is 2D, you can use libSDL. A good example of game written using it is The Battle of Wesnoth. SDL uses DirectX on Windows, it's just a thin wrapper on it.
If your game is 3D, use OpenGL. For example, Quake 3 uses that library. You can find tons of examples and documentation on it. Of course, there are many libraries that wrap OpenGL, so you don't have to do low-level stuff. Look into OGRE, Crystal Space, etc.
As for the basic C/C++ libraries and functions compatibility, it's best you install some Linux and simply run man page for the function to see if it exists. Of you can look it up on the Internet.