I'm making a component which burns disks with cdrdao.

Why?
Why not burrrn: (burrrn is great but...)
-it's not foobar (see below)
-There are some things in my collection it can't do
-it may just be my imagination, but it seems to take FOREVER, especially when replaygaining
Why in foobar:
-foobar holds my music
-I like the idea of being able to burn anything foobar can play.
-possibility of RG/DSP/Dither
Why not nero:
-I don't have nero
-don't tell me to get nero. $100 just so I can burn? I mean, it turns a fully functional foobar 2000 into one of the most expensive players out there. Winamp pro is only $15.00 in comparison, and man, I SO want to be done with winamp.
-with nero expired demo I have (old version) I get:
--SLOW!! though successful burning
--A fat program on disk I can't even use
--I have NEVER, at any time, even with a disk in etc, been able to select a burning speed
-with nero demo activated with a pirated key (still old version) I get:
--A hurting conscience
--A fat program on disk I never use
--Fast burning with at least 80% coasters (@$%^* it)
--I have NEVER, at any time, even with a disk in etc, been able to select a burning speed
why not my component:
-It's not ready yet
-I'm a sloppy programmer
-you need to get cdrdao working on your own. This may include installing aspi and registry tweaks.


I've already got the component working to the following specs:
1) A very ugly, and (I suppose) non SDK compliant gui.
2) Can convert files with/without RG/DSP/Dither
3) Can burn any selection which will automatically be in 2ch/44100 sample rate. (I tested, and it works on my machine)

But there are still bugs and issues.

1) My current code has a good chance of not working with 9x due to the way that my code redirects/launces cdrdao.
2) I'd like to make the gui more like the others I've seen in the SDK, and also make it able to show progress info from cdrdao. Right now, it's unresponsive while cdrdao is working. I will probably though give up on this component before I get to that point.
3) Files like my SPC's convert to 3xxxx something hz, which offends cdrdao and therefore my component
4) I suppose mono/multichannel files will have the same issue.

And there are things which would make this so much sweeter:
1)TAGZ'd cd text (I might do this)
2)Theoretically possible to choose dsp settings individually for each file. (or even for each moment down to the chunk level) I will never do either of these though. I can't figure out the win32 api that well.
3)With some extra control over the toc, the user could do cdrdao-like stuff to the cd, maybe like cutting a track short if you want.

My intentions are to make this component work for me, and then release the source code to anybody and everybody who would care to turn it into a respectable foobar component.


So, I'd like some help.
-regarding resampling:
1)I'm pretty sure I'll need to add the resampler at the end of the chain. Is this the right place for it?
2)can I leave the resampler in the chain when the file is already at 44100? What I'm really asking is what the resampler will do? Will it do nothing and not chew cpu? If so, that would make me really happy, and I'd feel free to leave it in the chain, thus simplifying my life.
-regarding switching to stereo:
1) How will convert 5.1 to stereo behave on non 5.1 files? Will it do nothing and not chew cpu?
2) How will convert mono to stereo behave on non mono files? Will it do nothing and not chew cpu?


Ideally, I'd like to just tack these dsps to the end of the chain like this:
-convert 5.1 to stereo
-convert mono to stereo
-resample
And leave them there assuming they won't do anything harmful/expensive when it doesn't matter.

Great. I've been waiting for a freeware CD burning alternative in foobar from the beginning. Let us know when you have a version available for public testing.

OK, here is my component. I call it tginn. You can get the source code/dll at www.geocities.com/popatr/tginn.html


Tginn still has bugs, but the ones I know about are visual or can be avoided. It is usable by me, and as I said, I'd probably quit once the component worked for me.


DISCLAIMER:
USE Tginn AT YOUR OWN RISK. I.e. I make no guarantees as to the fitness of tginn for use as a burner, or for any other use... Even reading the source code or this documentation might harm you. I won't be help responsible for any damages you recieve by using tginn or any items related to it.
However, I promise that there are no intentionally malicious items in tginn.
Read the known/suspected bugs section to know how to avoid the avoidable bugs.

LICENSE:
I don't know about legal stuff, but you have my permission to do anything you want with my component/sourcecode.
HOWEVER- you may be limited by the foobar/cdrdao licenses and/or conflicts between the two. And maybe the laws of your country. It is up to you to study these out for yourself and find out what you are allowed to do.


Note:
You should not think of this component as under development. I might watch this forum for a while to think about fixing bugs. BUT DON'T COUNT ON IT!! What would be really cool is if someone ELSE felt to make this component respectable.

Installation:
1) download a version of cdrdao from the cdrdao website
2) copy both cdrdao.exe and tginn.dll to your components directory.
3) get cdrdao working which might include-
3.1) installing an aspi layer
3.2) tweaking the registry
Don't ask me for help on getting aspi etc installed and working-- maybe installing burrrn will do all of this for you. Or maybe not..I actually have no idea.

Usage:
1)select the files you want burned, right click, and choose "burn disk with cdrdao".
Note- you are responsible for not selecting too much music for your disk.
2)Choose your options
Note- If you want to change the speed, you are responsible for typing in a speed which cdrdao likes. I don't know what cdrdao likes, since I just leave it empty (max speed)
3)click burn

This seems to do what it should.

Unknown areas:
1)I have not tested cdrw blanking since I don't have any.
2)I have not tested unlock drive 'cause my drive never locked up.
3)I have not tested the speed values, 'cause I just leave it blank for max speed

Known/suspected bugs:
1)The writers dropdown will display all devices which are reported by cdrdao's scanbus command. I suspect that this is more than just burners. Therefore, you are responsible for choosing an actual burner. If you choose something else, cdrdao maybe will ask for user interaction (which my component doesn't allow) and hence will lock up the component. The worst that I suspect will happen is that you will have to End foobar manually-hence losing any playlist stuff that hasn't been saved--by that, I mean that foobar won't get a chance to do it's automatic playlist saving at the end.

2)Oddly, if any window is up when you activate my burner, it will switch to such window, and you will have to switch back to foobar. I'm not motivated to fix this.

3)The display may go unresponsive while cdrdao is working. (the only things which should take any amount of time is burning/blanking, so that's the only time you should be able to observe this) From what I've seen, the lockup ends when cdrdao is done. I know of no harmful side effects.

4)A blank cd-r/rw disk must be in the burner before you push burn. Otherwise, cdrdao will ask for input which you can't give. Hence, it gets locked up. So... put in the disk.

Note- the unresponsive gui bug seems to not happen as long as foobar is the only thing up and you don't do !anything!

Enjoy, or not, at your pleasure.

I guess you should slap some kind of established license onto this if you want other developers to mess with your code, otherwise they might tend to get a bit insecure. Might I suggest a BSD style thingy, like:


?

I took your advice. I hope I did it right.

I get a with this plugin. I put foo_tginn.dll, cdrdao.exe and cygwin1.dll into my components folder. The ASPI and reg stuff are OK, I've got that working a long time ago, calling up cdrdao from commandline with a "cdrdao.exe scanbus" does what it's supposed to as far as I can see, so I guess cdrdao is working allright... But foobar2000 won't load this component.... Are there any dependencies I'm not aware of?

Running fb2k 0.8.3 on XP sp2, BTW.

Huh, I don't know why it does that to you. I did a google on it though, and I saw that some other components had similar things happen to them because of msvcrt71.dll was not present on the person's system. You could install that on your comp.

Or, you can try to redownload my component. I found on the same topic that some linking flags _might_ resolve the issue without the person having to have msvcrt71.dll, so I recompiled with the suggested flags. I don't even know if that was the problem, but you could try it and tell me if that does it for you.

Figured it out. Your component actually demands this full list of libraries to load:

msvcp71.dll
msvcr71.dll
msvcp71d.dll
msvcr71d.dll

Unfortunately, when I then choose a few songs to burn, foobar simply crash....

More investigation:
OK. I now replaced cdrdao.exe with the version from my Burrrn installation and cygwin1.dll with the version from my Cygwin installation (conflicting versions of cygwin1.dll in searchpath can lead to crashes, I've experienced that before), instead of named binaries from "cdrdao-1.1.7.bin.x86.win32" from CDRDAO site.
Now, let's see how the burning goes....

OK. Seems a cd got burned. It's playable. Gotta go soon, so I can't listen through it all, but it plays on my CD player....

Probably conflicting versions of cygwin1.dll in searchpath that caused the crash....

But one thing:
It leaves all it's temp files (wavs and toc) in foobar2000 root folder and it doesn't delete them afterwards. There really should be options for choosing temp folder and to delete temp files after (successful) burning......

I am interested in trying this out - I can't find a copy of msvcp71d.dll (the debug) anywhere. I did manage to find msvcr71d.dll. EDIT - disregard - found via obscure link.

anyway: Got it working, by copying Mr_Rabid_Teddybear's suggestions to a tee. Resulting disc is satisfactory.

Current gripes: no progress feedback, freezes foobar ui as a whole during burn (playback is fine - but included in ui freeze is inability to skip through playlist items, even via hotkey).

Cool. It seems to me that the marrying of Foobar and CDRDAO is long overdue.

However, Peter's post here possibly suggest why this hasn't happened before. I don't fully understand the licensing issues...

Here's another thread on the foo/cdrdao subject.



I would love to see this component flourish into a really solid and useable part of Foobar.

I do have Nero installed, but Foobar and CDRDAO just seems so right - like ice cream and jelly.

Congratulations on starting the project at least.

I deleted cygwin1.dll from my components folder. All works OK. As I got Cygwin installed, cygwin1.dll is in my searchpath already, and it seems cdrdao.exe are capable of finding it there. So now I won't get issues with conflicting versions whenever I update Cygwin. (Cdrdao depends on cygwin1.dll, incase anyone wondered....)

I am not specially knowledgable in licensing issues, but I seriously thougt you could link to a GPL'd binary from non-GPL'd software as long as you're not using any GPL'd bits of code within your application....(?)
Just look at e.g. Burrrn or Burnatonce. Theire both frontends for cdrdao, non of them have a license that even comes close to being GPL compatible....
And you can get a component for foobar called foo_mad. Seems that's OK as long as it's a separate component the user intalls him/herself. MAD is under the GPL.

That would be my understanding. The component may require the CDRDAO executable, but it doesn't use any CDRDAO code. I guess this is similar to selling (or releasing) a Windows application - the application requires Windows to run, but doesn't need to adhere to Microsoft's licensing.

Exactly. And as foo_tginn now are under a very unrestricting BSD style license that should work together with both CDRDAO's GPL license and foobar2000's closed license (as far as my understanding goes), I think popatr should be in the clear.....

foo_mad *does* violate GPL, by using GPL code together with non-GPL foobar2000 SDK code. However, author of the GPL part clearly doesn't care enough to even reply to kode54's emails asking for permission.
There have been cases of GPL software authors shutting people's projects down because of linking GPL code against non-GPL code in same binary (even while keeping whole binary opensource!).
I guess you're safe with GPL code being in separate executable (in worst case you can tell people to download it separately).

You know, when I build the diskwriter from the sdk, it ends up with those same msvc dll dependencies. This is odd, since the version I get with foobar_special doesn't need those dlls. maybe someone could advise me about how to end the dependencies on those msvc dlls. (maybe I've come across a limitation of the free vs.net I got through my cs department... when I read the license, I couldn't see any distribution limitations, but maybe they ensure unneeded dependencies in certain cases, to limit your distribution capability. Or maybe I'm just being paranoid.)

Anyway, I'm going to try to fix two things--the unresponsive gui issue, and I want create the ability to send a ctrl-brk to cdrdao at any time. This will allow the user to end an unresponsive cdrdao, which should also work in the case when cdrdao is looking for user input.

You appear to be using MSVC 7.1 compiler. Old MSVC 6 compiler - which was used for foobar2000 0.8.3 release - allows you to use MSVCRT.DLL for standard C/C++ functions; that DLL has been bundled with OS setups starting from win95b so it's safe to assume everyone has it by now. Unfortunately same compiler settings result in new runtime DLL references (MSVCR71.DLL etc) under newer compilers. You can avoid it by changing all foobar2000 SDK projects and your project to use "multi-threaded" runtime library (see: project properties / C++ / code generation) instead of "multi-threaded DLL" which it currently uses, but size of your own DLLs will go up.

I understand you are not motivated to do extended work on this component, but I would have liked to see options like setting a temp folder and delete temp files.

As features goes; CD-TEXT support like Burrrn does would have been nifty, but that's maybe stretching it......

If this is true, then I guess this component has been compiled in debug mode...which is quite unnecessary, it should be compiled for release. (IIRC the VS options)

Well, the new version is up.

1) The gui doesn't go unresponsive for me anymore. One user commented that he couldn't even send a command to foobar via hotkey. I tried it now, and I can.
2) You can send a ctrl-brk to cdrdao by pushing the new button on the right. This does stop cdrdao if it's looking for input, or otherwise wasting time. I haven't tried this during burning--I never felt like wasting a disk on that test. As I said, I don't have cd-rw's. (One note-- The ctrl-brk still doesn't affect the unlock drive command, but it should be fine since that command has never wasted time or asked for user input on me)
3) The dependencies on the msvc 7.1 dlls should now be gone. Thanks to zZzZzZz for helping me with that.
4)This is the release build. Thanks to kalmark for pointing that out... I was building the release version for you guys, but the post-link step still copied from the debug directory into the components directory!! (duh on me) So yes, I was accidentally giving you the debug version. The release version is smaller.
5)The component now cleans up after itself. (deletes the wavs and toc) unfortunately, I still don't let you choose the temp directory, and I don't offer to keep the temp files around. If I get around to improving this again, that would definitely become an option I think.

One quick note... tginn will work with later/other versions of cdrdao if I improve the way that my code parses the results from a scanbus. I'm thinking I should.

You could test during a simulated burn.


It is also possible to build with MSVC 7.1 and link against msvcrt.dll, but since you appear to be using the STL, this won't make any difference.

Slight hacking makes it possible to force link the msvcrt.lib from MSVC 6, but that doesn't work so well depending on the complexity of the C++ code you are using. (again, non STL) A more successful solution is to use the msvcrt.lib from the latest Platform SDK, or maybe it's from the latest Driver Development Kit, which is not available for free.


Easy to fix on all targets in the future if you use the environment variables to reference project/intermediate/output directory.


For now, you can refer to these functions, if you aren't already using them.

UTF8API_EXPORT BOOL uGetTempPath(string_base & out);
UTF8API_EXPORT BOOL uGetTempFileName(const char * path_name,const char * prefix,UINT unique,string_base & out);

Although, now that I think about it, it would probably be safer to use GetTempPathA/GetTempFileNameA directly. I'm not sure if cdrdao would accept a Unicode path properly, if it is even possible that the user profile directory contains characters outside the system codepage. (Or, codepage for non-Unicode applications as it is now.)

I can confirm that the new version allows hotkeys, but I did something other than *nothing* and it mitigated focus and mouse input on the main fb2k window. Keep it coming, looks good so far

Burrrn does not install any ASPI layer. Furthermore, it uses a special build of cdrdao from Burnatonce with something called "burnatonce extensions", which include as far as I understand, the option to use SPTI.

Anyways, a quick-and-dirty on making cdrdao work:

There's a lot of opinion on which ASPI and such, but I've been using the often recommended Adaptec ASPI layer v4.60 (1021) for ripping and burning for years on both w2k and xp without a single problem. I've installed this with ForceASPI 1.7. You can find instructions and download links on this page. In short; unzip, run DUMPASPI.BAT to dump current ASPI layer (if any), then run INSTASPI.BAT to install 4.60(1021). Reboot. Use aspichk.exe to verify the installation.

The mentioned registry tweak must be the same that comes with cdrdao download in the form of an "aspi.reg" file. I'm not sure if this is needed, but theres been reported that it can be necessary on w2k and xp to make things work. It doesn't harm to apply it anyways, that I've figured out. You can do same by copying code below into a textfile, rename this aspi.reg, doubleclick, answer yes.

Also, cdrdao needs cygwin1.dll in same folder or searchpath. This comes bundled with cdrdao. But take care that you don't have multiple versions of cygwin1.dll in searchpath as this, as I found out, might lead to crashes....

That should be it, really....

Uh. Strange thing. I put back the cdrdao.exe found in "cdrdao-1.1.7.bin.x86.win32" from CDRDAO site. When I choose files for burning, foobar2000 crashes immediately. I then overwrite that one with the version from Burrrn installation again, and all works hunky dory. I was obviously a bit to quick blaming crash on conflicting versions of cygwin1.dll....

When I tested the previous version last night (my first test) I got an instant foobar crash also.

This morning, at work, I have put burnatonce's cdrdao.exe and cygwin1.dll into my components folder, as well as the latest build of foo_tginn.dll.

I then got this error:



I am running a very lite version of foobar.

I downloaded foo_dsp_extra and I now get an instant crash again.

However, this machine doesn't have a burner, so I'm wondering whether this is a cdrdao instantiation problem. I'll test tonight on my machine with a burner and let you know.

I thought it was worth pointing out that you may need to specify that the component needs foo_dsp_extra (as does Audio CD Writer).

I also think your error dialogue should specify that it is a "Thank God It's Not Nero" dialogue.

Also, it may be an idea to use the foobar component versioning - each version has been 0.0 so far.

I know you're not really interested in supporting this/improving it solely for the masses, but there's the info - do what you want with it.

Edit: Oh... and thanks.

I'd rather think of highly buggy alternatives as of free advertising for Nero.
Anyway, shame that he only made it for me to add new offender list entry - in case he really can't be bothered to fix it. I'd rather live without specific feature than with implementation that works on random basis.

As I said at the start:

I still think there is a niche there, for those people who don't want to use Nero. CDRDAO seems the obvious (only?) choice as a free alternative.

However, I would like to believe that the development was in the hands of someone committed to making the component "really solid". When you are burning to CD, which is using up resources (albeit cheap) and possibly creating an archive, I think you need to have complete confidence in the result.

Unfortunately popatr has made it clear that s/he would rather someone else completed the development - but I don't have much faith in that happening. I'm hoping that the interest shown in the component will encourage him/her to see it through to the bitter end. It is promising that development is currently continuing quite rapidly.

Bear in mind that it is still at version 0.0.

All of the hard crashes you guys are reporting, (I think) are related to the way I parse burners. Right now, it is (shamefully) very dependent on the version of cdrdao you have, and is not error-tolerant. As I said in an earlier post, "I think I had better fix this." I will.

As to the the error message. Yes, it needs those dsps, and is informing you of that. Nothing bad will happen, AFAIK, for not having those dsps. You just can't burn with tginn until you do.

Then could the error message mention foo_dsp_extra? I only managed to get it so quickly as I remembered seeing something about the SSRC sampler being included in some versions of the Foobar installer. Some users are not so familiar with Foobar components, or the absence thereof.

I realise that it is a handled error, and that's obviously a good thing. I just think you could easily save some bug reports from people who don't realise they need foo_dsp_extra.

I expect most people don't go for the Lite version, and therefore this won't be an issue. It just seems like a simple way to stop any confusion...

I look forward to the next version.

I think this is highly promising software at alpha development state. Offender list entry at this stage is a bit premature, don't you think...? It could rather be marked with a "Only-for-testing-by-those-who-know-what-theire-doing" tag
Hope popatr (or somebody else) will follow this through until achievement of proper release state.

Damn, that counts me out.

I consider myself a member of the "bored-compulsive-and-opinionated" group of users.

A new version is up.

It should be more tolerant of other versions of cdrdao. I've tested on the 1.1.7 from the burrrn install, and the 1.1.9 which I just compiled. (1.1.9 is incomparably larger!), and it works on both. I expect it will be just fine on other versions too.

At least I don't expect tginn to crash anymore, even if it's not friendly with a given version of cdrdao. If it doesn't know how to parse the burners from the scanbus of that version, it will (should) simply say that it couldn't find any burners, and therefore it will exit.

I did calm down the error message about not finding the needed DSPs, and it does mention that SSRC is in foo_dsp_extra.

I hope this version can at least handle errors semi-gracefully (is well behaved), and is stable/good enough to not get put on the offenders list. I WOULD like to avoid that, so I'll keep up the watching of this thread.

Thanks!

Could anyone make a Win32 compile of cdrdao 1.1.9 available, BTW? Or does anybody know of such? I've only found 1.1.7 precompiles for Windows, and I don't have a Windows compiler and wouldn't know what to do if I had (the only compiling I've ever done are the usual ./configure make make install on *nix).

You said you had cygwin, yes? You can do ./configure, make, make install on that too, assuming you have the right packages installed. (that's what I did) I don't feel like I can host a cdrdao on my site, even if I'm allowed to. Not that people a hungry for my bandwidth but...

I just compiled CDRDAO 1.1.9 with cygwin using the provided default scripts, but it gave me a 3Mb exe file (!!). I think you'd better stick with 1.1.7 if everything is working fine.

You could try to UPX compress that executable maybe...

You could try stripping the debug info first.

bear in mind that my knowledge of compilers is restricted to:

./configure
make
make install

so you have to be more specific and enlighten me on how do I do that.

I have uploaded an cdrdao 1.1.9 binary for Windows here:
http://www.hydrogenaudio.org/forums/index....showtopic=33945

Hope you enjoy it!


Edit: I compiled this late october last year, for the possible use in burnatonce.

Just out of curiosity, what do you have to add in the ./configure, make and make install commands to get smaller exe files?

Run the usual './configure; make', but at the end run 'strip cdrdao'. After that you can even use UPX to compress the file. Thats the way I got my cdrdao.exe down from 3MB to 230KB

thanks a lot. that really works.

Thanks, mate!
A bit OT, but I just have a very minimal Cygwin install, basic install plus Open SSH, Vim and a few others. Any quick-and-dirty overview on which packages I'll have to install to do this myself? (With a full Linux install this is usually present so things just work...)

And the strip executable thing, does it come into the command sequence like this:

./configure
make
strip something
make install

Did I get it right?

@Mr_Rabid_Teddybear. That command sequence is right, exept you dont really need to run 'make install'. cdrdao.exe is selfcontained, so simply copy it to your foobar2000 directory.

To compile in cygwin you need at least GCC and make, but not exactly sure if you need even more.

Honestly, I don't know exactly what you need either, because my cygwin install is quite huge.

I think I have all the default packages from devel and libs.

Thanks. I managed to compile it. Seems I got away with installing make, pkgconfig and then gcc-core and gcc-g++ and whatever packages those automatically dragged with them... At least it was enough for compiling cdrdao.

I compiled cdrdao 1.2.0 that's up on sourceforge now. My compile and experiences here.
It behaves very different from 1.1.9. Burning failes like shown in this picture:



Just wondering what's going on... I'll just revert to 1.1.9 for burning (which work fine)....

Hey, just wondering if anyone was going to pick this up and maybe add CD-TEXT support any time. I never really liked the burninate component because of the nero dependency, so this component is really kick abs. cd-text would just make me pee my pants. Thanks.