Quote:
Originally Posted by jfcarbel
Seems the focus is on Unicode and moving away from Delphi.
|
Yes, not being able to handle Unicode file names and meta tags was an annoying limitation. And it is the main reason for the re-write. Delphi 7.0 can handle Unicode (UTF-16) strings too, but it's a real pain, as all the basic string manipulation functions and all the "native" GUI controls are ANSI. This means you'll have to re-write a whole lot of "standard" functions and/or use third-party components all the way. AFAIK newer Delphi versions provide better Unicode support (the basic "String" type is "WideString" now), but the update would be too costly for me and probably break a lot of my code anyway. So I decided to make a clean re-write with C++ and the Qt Framework, which provides full Unicode support as well as a sophisticated "internationalization and localization" tools. And, thanks to Qt, even cross-platform support is within the realms of possibility. However my focus is on Win32 and MSVC for the moment. Next step would be making the application compile with GCC/MinGW too. Then, maybe, make the move to Linux and/or MacOS...
Quote:
Originally Posted by jfcarbel
Is there anything else planned?
|
First of all the goal is to get everything working that had been working under the 3.xx series. This includes encoders (output formats), decoders (input formats), filters and so on. Something that turned out to be a HUGE problem is that most of the command-line tools that I use do
not support Unicode file names out-of-the-box! If the GUI front-end handles Unicodes file names just fine all the way, but then the CLI encoder/decoder mangles the commad-line parameters (by converting them them to ANSI and replacing each "foreign" character with a "?" character) you end up with the same Unicode problems as before. Consequently this time I have to make my own custom builds of most CLI tools (rather than using the pre-compiled binaries) and hack Unicode support into their code...
(I still wonder why nobody seems to care about Unicode support in their CLI tools. It's not
that hard to do, really! I'm not familiar with their code at all, but I usually can do it within 1-2 hours. A person who
is familiar with the code and already has the required build environment set up on his/her machine should be able to do it even faster and much cleaner)
Quote:
Originally Posted by jfcarbel
As I had a need for an audio conversion tool that also had built in:
- CD conversion on the fly to mp3 with integration to CDDB/freedb for auto tagging
|
That's not really in the scope of an audio encoder front-end. There are various CD rippers available, so I don't want to re-invent the wheel. Maybe I will look into "embedding" one of the existing CD rippers, once I run out of ideas for other improvements. Currently there are enough TODO's on my list...
Quote:
Originally Posted by jfcarbel
Normalize via ReplayGain
|
Normalization will be supported, like in the 3.xx version. However I will use Volumax (or SoX) for that purpose.
AFAIK the ReplayGain tool is mainly interesting if you want to "normalize" MP3 and/or AAC files
without having to re-encode them (it modifies the MP3/AAC bitstream directly or adds a special tag).
As this is an audio encoder front-end, which you use for the task of
re-encoding, we can apply a "hard" normalization just as well...
Quote:
Originally Posted by jfcarbel
metadata cover art support as well
|
This would be possible if: The encoders that are used (LAME, OggEnc2, NeroAAC) support adding "cover art" via command-line
and there is a convenient way to extract the cover from existing files. Currently I use MediaInfo to extract all the meta information from the input files. But I don't think it can "extract" the "cover art" too...
After all I really can't understand why people want to have a cover embedded in each audio file. Why not put a plain JPEG file into the "album" folder
once, and avoid the redundancy?
(Is that yet another "Apple/iPod" crankiness, like forcing the user to use an
incorrect .m4a extension for MP4 files ???)
Quote:
Originally Posted by jfcarbel
As an added bonus it can take audio from video files including FLV, MP4, VOB. Not sure how often I would use that though.
|
MP4 should work, at least if the audio track is AAC. That's because AAC audio files are usually stored in a MP4 container, regardless of whether they have video or not.
For FLV and VOB, I will have to look into a suitable demuxer. There is "FLV Extract" and it even has a CLI version, but it's written in C# and thus needs the .NET Framework
(And I want to avoid dependency on the .NET Framework or the Java Runtime Environment by all means. I'm a big fan of "self-contained" and "portable" software ^^)