Maybe I should have read how he was using the registry, but you are correct, you cannot write settings to the app.config at run-time. Your approach to a custom XML file would be correct and you could serialize that to a class if you really wanted. I'm not big on serialization, but some ppl find it easier to deal with than XPath and the XML DOM.

I'll get my coat... (as we say in the UK when we get something hopelessly wrong)

Quick update: I haven't stopped working on this, but I have "upped the ante" so to speak...

The project is now called Omni Encoder, and it works with multiple encoder back-ends, can be run from within multiple rippers, and can automatically import tracks into various media players. Automatic art downloading and (optional) tagging is also planned via Amazon.com. The goal is a one-click rip to your media library.

Version 1.0 will contain:

Encoders: Lame, iTunes AAC and Apple Lossless.
Ripper integration: EAC
Media player integration: iTunes

The project will still be open source, and the engine is easily extensible to new encoders (i'll probably add Ogg Vorbis soon myself, but I want to get version 1.0 out as soon as possible.)

Anyhow, this is admittedly starting to sound like vaporware, so i'm getting back to work on it right now! I'll start a new thread when there is an anouncement to make.

Any news?

Sure... I've been working on it a lot lately. Previous update is all still valid... this is what I have left to do:

1) Add the Amazon art feature (which shouldn't be too hard).

2) Switch the iTunes frontend to Quicktime instead (scripting the iTunes interface seems clunky vs. using Quicktime API calls).

3) Add the cool Razorlame-style histograms to the Lame frontend (not necessary, I know, but I originally had my heart set on a simple RazorLame replacement, and histograms seem like a requirement for that.)

4) Add documentation (for both usage and the API).

Once these steps are done, I'll do an informal beta on HA for bug squashing, and then cut a version 1.0. I'm a perfectionist though, and every time I work on it I find more things to fiddle with... this is the first project i've done of this magnitude so I really didn't realize the amount of time it would require, and probably still don't!

The easy way is to use the my.settings class. You can create your settings into the GUI (select the project in the solution explorer, select properties and in the properties goto the tab settings). You can read and save the settings with the my.settings class. The config file like <MyApp.exe.config> is saved in the same directory as the exe file. You can access the settings like this <my.settings.leftborder> and you can save with my.settings.save() method.

yep, got it working already actually... quite easy. There will be no registry footprint at all with this program. In C# though there is no "my" object (just in VB)... gotta access them through Properties.Settings.Default.xxx. Also (at least .NET 2.0) keeps user settings in C:\Documents and Settings\<username>\Application Data so each user can have separate configuration files.

Update on my previous post:

1) Automatic downloading of album art via Amazon.com is working beautifully.

2) I've ordered a book on the QuickTime COM API ($70! God damn developers don't document anything, then they have the gall to charge for a book!)... so once that arrives, I should be able to get AAC / ALAC support working - hopefully next week.

3) Still to do.

4) Still to do.

Looking pretty good so far... everyone who has seen it asks how much it is going to cost

keep up the work and don't forget to drink lot's of coffee

Do you have any screenshots we can look at in the meantime?

Tags are parsed automatically from any installed file formats when you drag/drop them into the list.

Album art is automatically downloaded 9 times out of 10 just by clicking on the art column. If there is insufficient search criteria (see how the Perfect Circle track doesn't have an album name?) then you'll get the following dialog box:



Installed front-ends get loaded at startup and appear here. Notice that you can encode to 2 formats at once (a nod to Wack and the like):



Depending on which front-ends you selected above, you will be presented with customized settings tabs like so:



Hope this short tour peaks your curiosity, and explains why this is taking me so long to finish!

Jeremy

Looks great! Should replaygain analysis be disabled in lame if you track normalize? I'll let you ponder that..

That's just the lame tag calculation... the mouseover tooltip explains that this option doesn't actually "do anything". i know some people like to disable it since it saves a bit of time.

Grrr... posted those images and then the power went out in Calgary. Either my server is down, or my connection is. I was working on coding via terminal services as well. Guess I'll try again tomorrow.

I don't see any use for that "Copyright flag" option. It only mars the otherwise streamlined dialog box.

HTH and happy hacking.

This is looking great Jebus! I can't wait to try it out.

Ditto!
C'mon Jebus... you're killin' us here!

Dear Jebus,
The provision for custom command line is missing from the final picture. Please do not drop it because some may misuse it. It is necessary if you want your program to be fully useful for all.
--Rigapada

Give me a good reason to include it, and i'll consider it. Without one though, i'm not adding it for the same reason I'm not adding a WMA module... its a bad idea and people WILL misuse it.

It has been found in some cases that a the ath sensitivity switch could be useful (high replaygain settings on some albums). Setting a custom scale could be nice too (custom normalizing). So could resampling (for voice modes)

Aesthetic wise, I like the design.

Btw, does this encoders support MP3 to Mp3 conversion? (just like changing the birates of the files?) thanks.

That sounds like a great idea! It would be the most elegant solution with dealing with bitrate bloat with loudly mastered music. Perhaps the athlower switch would be better for this pourpose? And perhaps you could even use this for quiet music also, to ensure that important details don't get lost below the ATH threshold. But as guruboolez's test one had shown, lame didnt really have any problems with this. Althogh I bet it would bring peice of mind to many paranoid people out there.

Yes, any installed codec can convert to any other installed codec. Even the same one.

Update:

I've also added tag re-writing support, since all the infrastructure was there anyhow. So Omni Encoder is now a multi-format tagger as well!


You can do the following:

* Transcode from any number of formats to up to 2 formats in one click.
* Encode directly from EAC to up to 2 formats at once.
* Tag or re-tag multiple files in multiple formats at once.

Do you have anything to convert between cue sheet formats?

With the encoding from EAC, do you have the option of image files and individual files for each track?

What about saving the log file in a custom location?

cue sheets aren't used... EAC runs a CLI program called EACRun after each track is ripped. EACRun, on the first instance, starts Omni Encoder, sends it the track information via inter-process communcation, and then exits. Each subsequent call to EACRun simply finds Omni Encoder and sends it the next track. After the last track is ripped, Omni Encoder automatically downloads album art and begins the encoding process.

Omni Encoder, when started in standalone mode, does not listen for IPC calls, nor does it automatically begin the encoding process. Make sense?

As yet, Omni Encoder does not have any sort of logging capability. Is it something people need?

1. It might be good to add the ability to save the cuesheet, move it, convert it to the format of the files you are ripping (image or individual files).

2. So, when being used with EAC, no encoding is done until all ripping has completed? Is that right?

3. So, can you only use EAC to rip to individual files then? No images?

4. Some people would like internal logging of what OmniEncoder is doing. I was actually referring to the EAC log file and being able to save it along with the encoded files in a directory of the user's choosing.

II would like to be able to set the lowpass too. For example, sometimes I am forced to transcode from lossy to lossy. Using a lower lowpass than the default leaves more room for more important audible frequencies and can effectively lessen the additional artifacting a bit.

Also, a custom sample rate may be needed for technical reasons. Not all devices or software applications support the default sample rates that LAME uses with various quality/bitrate/stereo-mono options and source file sample rates.

Jebus, it is not your problem if some people misuse the available options. If they are not happy with the audio quality they get with an improper command line string that would just be a good lesson for them. Don't take the option away from those who know exactly what is needed and why.

Edit: typo

1. I'm not sure I understand why cuesheet support would be a useful feature... if thats what you want to do, I don't see the need for Omni Encoder at all.

2. That's correct. Since Omni Lame supports album gain, art downloading etc it makes sense to rip first, encode afterwards. The EACRun instances are almost instantanious - they just send a message to Omni Encoder and then exit.

3. You can use EAC to rip to whatever you want, but yeah... Omni Encoder is designed to work with EAC in track mode, not image mode.

4. EAC is still going to work like it does with any other encoder... so you can save the log file wherever you want.

ATH: This is in regards to --V5, no? Wasn't this already fixed in 3.97 beta 2?

Scale: You can set this manually in a sense, by enabling normalization and setting a target volume (default is 89dB, of course).

Lowpass: I think it is unwise to second-guess the LAME developers with regards to their lowpass choices.

Sample rate: What devices, specifically, can't support which sample rates? I won't include the feature unless I can get concrete examples.

The LAME website is very specific in its GUI recommendations, and they WANT these features hidden. I will honor their request unless I can have solid, concrete examples.

The recommended LAME options are tweaked to be excellent compromises of various factors when the only goal is highest possible MP3 audio quality. Most of the recommended settings are optimised for standard 44 kHz/16-bit/stereo source files (like CDA). However, some situations may need other choices and LAME itself has excellent controls for that. I already provided one example of such a situation.

Devices that do not support certain sample rates are not uncommon. E.g. this device does not support 48 KHz MP3 files: Turtle Beach Audiotron. Even common users may have source files that are 48 kHz (soundtracks separated from home video recordings or other video files are typical examples). Some other devices do not support the lowest sample rates LAME produces (e.g. some DA converters).

For 99% of time I am happy with the recommendations, but when the 1% occurs I have found the custom command line dialogs that are available e.g. in Razorlame and some other GUI programs quite useful.

Also, testing of various settings is part of many HA members' life. Without that testing the current recommendations would not be possible. An easy to use custom command line option would make testing easier.

Edit: Edited a bit and removed the example screenshot since I posted a better one below.

The program looks great. Don't bloat it with too many redundant features, please.

I just remembered that I already made a proposition three months ago in this same thread:


However, of course you should do as you wish, Jebus. It is your program and if the design goal is to make the options as foolproof as possible then make it so.

You've made your case in that sometimes testing around here requires special tweaks in order to improve beta encoders.

I'll add a button marked "override settings" that brings up a separate window containing a stern warning and a text box for entering a custom command-line.

Good enough?


Progress report:

The core Omni Encoder functionality is almost complete, just have to finish up some things in the Encode() loop. Basic tag witing support is now included, with the stipulation that it does't rename/reorganize files. That will be a post-1.0 feature.

The Lame front-end should be finished tonight or tomorrow. Working on histogram parsing/drawing tonight.

The QuickTime front-end should be finished this week... still waiting on an API book I ordered to work some bugs out.

Next week is dedicated to code documentation and clean-up, and then I'll release a beta. Post-beta, I'll add some more front-ends. First up will be Ogg (flac, vorbis and possibly speex), and then MPC.

I've encountered a roadblock:

The QuickTime frontend won't work, because Apple has disabled the AAC export functions unless you obtain a license. VIA Licensing wants effectively $1 US per encoder, which isn't a big issue, plus $1000 up front (which is).

Now, i've sent them an email requesting leniancy on that $1000 fee in light of the fact that i'm a poor University student making a not-for-profit project (which is all true). In the event that they will not waive this fee, I will have to finish Omni Encoder without an AAC front-end.

If and when Omni Encoder is adopted by the community, we can then re-address how badly we want AAC support and perhaps collect a fund to pay the $1000. But I'm getting ahead of myself here... for now, I'll just finish up the Lame front-end and get this thing out the door!

EDIT: I've decided to bypass the issue by using the QuickTime APIs for tag reading and decoding of M4A/MP4 files, and just scripting the iTunes interface (in the same way iTunesEncode does) for encoding. Not as pretty, but it does the job (and is much easier, btw - I have an all new appreciation for Microsoft's extensive documentation. Apple - you suck!)

...and we're eagerly awaiting that!

So why not use Nero or Winamp libraries for AAC encoding? Is there the same issue?

I think the CT encoder needs to be commercially licensed ($ again), as does the nero encoder. Of course, the front-end could be made, but people would have to find their own AAC encoder binaries.

Then again, the perfect solution would be to use FAAC or whatever..

Does anyone here know how long it takes to set up an AAC encoder? Maybe I could start programming on one once I'm done school.

Thats why we need to use free and open codecs like Vorbis

I'm looking for a prgrammer to write a decoder mp3 librabry for a music video application would you be able to do this .

Encoding with suggested replaygain applied would be NICE!

I've decided to bypass the AAC licensing issue by using the QuickTime APIs for tag reading and decoding of M4A/MP4 files only, and just scripting the iTunes interface (in the same way iTunesEncode does) for encoding. Not as pretty, but it does the job (and is much easier, btw - I have an all new appreciation for Microsoft's extensive documentation. Apple - you suck!)

The FAAC has a low quality and it doesen't support AAC-HE and AAC-PS. It would be perfect if somebody starts on improving it. But it is definately a lot of work to make a good encoder.

Any news there, Jebus?

Yeah, sorry... temporary delay here as i'm loosing my job, moving to Vancouver and starting a new one... no time right now

Sorry to hear about that. Hope it all pans out ok for you. Keep us in the loop as time allows, ok?
Best of luck.

jebus,

I hope all is well with you, your new job and new location. I was wondering if you were still working on this, or are you still getting settled?

No biggie, take your time. Just curious.

Thanks for the response, citizenkeith... you've made me feel guilty about not finishing this, and I've been putting in some more effort this week. Basically I'm a total perfectionist, and since this is also a learning experience for me programming-wise, I've made many changes and started over a few times. Right now, as of this evening, it is almost complete.

Anything I say obviously at this point has to be taken with a grain of salt, but i expect to have it finished very soon - like in a few days. This latest version is quite a bit cleaner code-wise than the one I almost spit out in April, and I'm pretty happy with it.

I've got Nero and Lame modules running right now, and I'll complete Vorbis and MPC front-ends too before this goes beta. iTunes will have one, but it will be kind of an inelegant solution simply scripting the GUI (for reasons discussed earlier). I did pull some features temporarily (re-tagging, and multiple concurrent encoders) in the interest of having a solid, simple utility to start with.

Anyhow, off to bed...

Thanks for the update. Let me know if you need a beta tester.

Got basically one show-stopping bug right now (calls from EAC are on the wrong thread, and when I think that I've fixed the problem it still crashes, but without any debugging info! Grrr....)

Also the nice progress bars I promised aren't working, because AFAICT .NET's I/O redirection doesn't work properly. Might have to make some calls to old win32 (which I am unfamiliar with). Anyhow that can probably be fixed in beta.

Edit:

Showstopper fixed. EAC -> OmniEncoder mode works perfectly. Still have to finish Lame and Vorbis modules (Nero is working 100%). Need to add an output dialog as well (right now it just outputs to the source directory, which is fine for EAC mode but otherwise insufficient). Then I need to roll a click-once installer together and the beta is off!

It's done! But ClickOnce deployment appears insufficient, and I only have the free version of Visual Studio... so i'm waiting to "borrow" a copy from a buddy... should have an .msi installer rolled this evening.

If not, I'll just put them in a zip file. Either way you'll get to play with this by tomorrow!