Topic: Taper's Linux HOWTO

[homer420]

I've put together a small HOWTO for you tapers interested in using Linux for transferring recordings, splitting tracks, and burning CD's (and DVD's):

http://homer.homelinux.net/taper-linux-howto.html

For the last 3+ years I've been using Linux exclusively as the operating system for my digital audio workstation. And over this time I've been able to find comparable {free} applications for performing the common tasks of a taper. This HOWTO is intended to provide an overview of these applications, and provide links to where they can be downloaded. It also provides an overview and pointers to some scripts that myself and others have written to make many of these tasks easier for us tapers.

This is my first attempt at writing a HOWTO so if you have any feedback or suggestions for improvement please send them my way (dmaley at nc dot rr dot com). Enjoy!

--
"That's it!  You people have stood in my way long enough.  I'm going to clown college!"
-Homer J Simpson

[hzgone]

didn't read through the whole thing since i don't have a linux box running.  Which is sitting in my garage with no power supply but a good refrence when i get it running again.  +T

[chase]

Cool 

I have been running linux exclusively for the past year or so, currently running ubuntu.  I have been slowly working on a website of my own that will hopefully serve as a one stop place to find info on how to get/install/use everything a normal taper/trader will need, on any platform, windows, mac, linux.

[pigiron]

Hell yea! We need more Linux presence around these parts.

I'll try out some of those scripts... tanks.

Now that 24 bit's coming more into play, you may want to add some more poop on that. I've found that AFsp has been carefully coded and does a one step 24/96 to 16/44.1 dither/resample (and more). Looks like the main web page is down, but the code's at ftp://ftp.tsp.ece.mcgill.ca/pub/AFsp/

I've also got a version of wavbreaker that I've hacked for 24 bits on ALSA.

Now we just need to get a group together to work on a good metaflac app 

[homer420]

Now that 24 bit's coming more into play, you may want to add some more poop on that. I've found that AFsp has been carefully coded and does a one step 24/96 to 16/44.1 dither/resample (and more). Looks like the main web page is down, but the code's at ftp://ftp.tsp.ece.mcgill.ca/pub/AFsp/

I've also got a version of wavbreaker that I've hacked for 24 bits on ALSA.

Indeed I need to update w/ some 24-bit related info.  Been on my to-do list for months, but don't have any 24-bit capable hardware and thus just needed a push to get it done ...

It should be fairly easy to add 24-bit recording to my drecord script since arecord supports this just fine.  But it doesn't appear sox is able to dither from 24 -> 16 bit so I'll have to look into other ways to do this from command line which I can incorporate into the script.

Audacity should be able to handle 24-bit recording and dithering to 16-bit just fine for those looking for a GUI interface.

I've also got a version of wavbreaker that I've hacked for 24 bits on ALSA.

Can you post or send me a patch for this?  I've been working w/ the wavbreaker author on a number of things and I'm also maintaining RPM's.  If it doesn't introduce any problems w/ the 16-bit stuff I'll get it added to my packages.

Cheers,
Dave

--
"To alcohol!  The cause of, and solution to, all of life's problems."
-Homer Simpson

[homer420]

I managed to track down the AFsp page:

http://www-mmsp.ece.mcgill.ca/Documents/Software/Packages/AFsp/AFsp.html

Looks like some interesting stuff.  I'll have to start looking into it's capabilities ...

[nic]

while this is a nice resource, unfortunately, it doesnt tackle the main problem with Linux recording...configuring the interface driver.

even on the ALSA page, many cards that are "supported" arent, at least the digital I/O portion of the interface isnt supported.
take the M-Audio PCI cards for example...sure, the Envy24 chip is supported, if you only use the analog RCA I/O. it's been the case for at least the last 6 years and that is IF you manage to get ALSA to load the driver in the first place (I've tried with 2.6.x kernels and I still cant get ALSA to load correctly...)

those of you who use Linux to transfer digital recordings, what interface are you using?

[it-goes-to-eleven]

I believe the M-Audio problem is because they won't release specs for their gear.  The UA-5 seems to work fine.

One big problem I have with linux audio is the lack of good dither. It would save me a lot of hassle if I could just 24/96>16/44 from a command line without ever visiting windows. Audio and Visio are the *only* things I use windows for.

Simple stuff, like swapping channels, is very tedious in Audacity (I asked on the audacity mailing list and nobody had an easy method).  Improving audacity all comes down to more 'man years' of work required.

Most Linux audio tools don't do 24 bit well.  They quietly convert to 32 bit and back to 24, introducing noise.  Ecasound, as good as it is, does not seem to be bit accurate.  Kai does an amazing job of supporting ecasound but doesn't seem to 'get' the need for bit accuracy and that most hardware is 24 bits and not 32.

I'm sure that Linux audio will continue to improve. I was doing 24 bit laptop recording with linux for a while and it worked quite well (and I think ecasound was quietly converting the 24 bit data from my Minime to 32 bits and then back to 24 when writing it out...).  Ultimately, I decided I wanted to make recordings more than I wanted to hack Linux sound and fight battles over bit correctness, etc.  Sometimes you just want to drive the car, not build it 

[Brian Skalinder]

Most Linux audio tools don't do 24 bit well.  They quietly convert to 32 bit and back to 24, introducing noise.

During the editing process, you mean?  Many Windows audio tools do the same, or are configurable to operate in the 32-bit realm during processing.

Help me understand why using 32-bit math when editing a 24-bit file would create more noise?  I suppose on one hand, you're using more precise math during the editing.  But on the other, you must then dither back to 24-bit.  So are you suggesting the extra precision available from 32-bit processing is negated by having to dither back down to 24-bit?  Genuinely curious...

[mfisch]

Most Linux audio tools don't do 24 bit well.  They quietly convert to 32 bit and back to 24, introducing noise.

During the editing process, you mean?  Many Windows audio tools do the same, or are configurable to operate in the 32-bit realm during processing.

Help me understand why using 32-bit math when editing a 24-bit file would create more noise?  I suppose on one hand, you're using more precise math during the editing.  But on the other, you must then dither back to 24-bit.  So are you suggesting the extra precision available from 32-bit processing is negated by having to dither back down to 24-bit?  Genuinely curious...

Indeed that is most unintuitive. I would think a 32-bit workspace would make the processing _more_ bit accurate. Of course, I'm not sure you will ever be bit accurate with digital audio, there are some pieces of math that simply don't fit into a 32-bit float either .... course -- if its good enough for hollywood its good enough for us right? I think the approaches various processors take in the digital realm will have a much greater effect on the sound than the bitdepth they are working at however.

ps, is he talking about just recording?

24 --> 32 --> 24?
As in:
101010101010101010101010 --> 10101010101010101010101000000000 --> 101010101010101010101010 .. looks bit accurate to me.

[ethan]

+T

[homer420]

while this is a nice resource, unfortunately, it doesnt tackle the main problem with Linux recording...configuring the interface driver.

even on the ALSA page, many cards that are "supported" arent, at least the digital I/O portion of the interface isnt supported.
take the M-Audio PCI cards for example...sure, the Envy24 chip is supported, if you only use the analog RCA I/O. it's been the case for at least the last 6 years and that is IF you manage to get ALSA to load the driver in the first place (I've tried with 2.6.x kernels and I still cant get ALSA to load correctly...)

those of you who use Linux to transfer digital recordings, what interface are you using?

I use a RME Digi96/8 PST card.  The default mixer app for Gnome (gnome-volume-control) doesn't properly support this card.  However there's a great app available called rmedigicontrol, included in alsa-tools, which is specifically designed for use w/ RME cards.  It's extremely difficult for a generic mixer app to correctly support all the different soundcards out there, and the folks who do the majority of the work on these mixers focus on making them work well w/ the most common soundcards around (ie. low-end).  Fortunately there are a number of alternative apps out there which are specifically designed for the higher-end cards, and in general these will allow you to make use of the full feature set of your soundcard.

In the case of your example, M-Audio (Envy24 chip), the ALSA driver (ice1712) does indeed support the digital interface.  And alsa-tools also contains a mixer app specific to the envy24 chipset called envy24control.  I'd suggest giving this a try to see if it does the trick for you.

As for getting the alsa drivers to load/work have you tried any of the recent distro releases based on a 2.6 kernel?  I would highly suggest giving Fedora Core 4 a try (sorry I'm biased towards Red Hat - any recent 2.6 based distro should be fine).  It's taken a little time for the linux vendors to get all their installer and config tools working properly w/ the ALSA stuff, but the Fedora folks seem to have all the major kinks worked out now and thus the drivers themselves should "just work" after a fresh install.

Note: The alsa-tools package is not in the base Fedora Core distro however it is included in Fedora Extras.  So you'll need to install it using yum after doing the OS install.

[Lil Kim Jong-Il]

Nice to see you here homer.  I saw your page when you posted to oade a long time back and used some of that when I still worked in 16-bit.

Does wavebreaker handle 24-bit files yet?

Most Linux audio tools don't do 24 bit well.  They quietly convert to 32 bit and back to 24, introducing noise.

During the editing process, you mean?  Many Windows audio tools do the same, or are configurable to operate in the 32-bit realm during processing.

Help me understand why using 32-bit math when editing a 24-bit file would create more noise?  I suppose on one hand, you're using more precise math during the editing.  But on the other, you must then dither back to 24-bit.  So are you suggesting the extra precision available from 32-bit processing is negated by having to dither back down to 24-bit?  Genuinely curious...

Translating between int and float creates noise because rounding errors are introduced during the storage format conversion.  Try reading a 2G file into audacity and then writing it out to another file name.   You will rarely get an exact duplicate.

I have yet to figure out how to get audacity to stay in 24-bit int mode even though there is a setting that seems to be intended for that purpose.

[homer420]

I believe the M-Audio problem is because they won't release specs for their gear.  The UA-5 seems to work fine.

One big problem I have with linux audio is the lack of good dither. It would save me a lot of hassle if I could just 24/96>16/44 from a command line without ever visiting windows. Audio and Visio are the *only* things I use windows for.

Simple stuff, like swapping channels, is very tedious in Audacity (I asked on the audacity mailing list and nobody had an easy method).  Improving audacity all comes down to more 'man years' of work required.

Most Linux audio tools don't do 24 bit well.  They quietly convert to 32 bit and back to 24, introducing noise.  Ecasound, as good as it is, does not seem to be bit accurate.  Kai does an amazing job of supporting ecasound but doesn't seem to 'get' the need for bit accuracy and that most hardware is 24 bits and not 32.

I'm sure that Linux audio will continue to improve. I was doing 24 bit laptop recording with linux for a while and it worked quite well (and I think ecasound was quietly converting the 24 bit data from my Minime to 32 bits and then back to 24 when writing it out...).  Ultimately, I decided I wanted to make recordings more than I wanted to hack Linux sound and fight battles over bit correctness, etc.  Sometimes you just want to drive the car, not build it 

From command line you should be able to just use arecord (or my drecord script once I add the support) to get a true 24-bit signal written to disk w/out any sort of conversions.  However I believe Brian Skalinder is correct that most audio editors (Windoze, Mac, etc) will convert to 32-bit for doing the actual signal processing.

Audacity definitely has some shortcomings.  It's come a long way since I first started playing with it, but certainly still has a ways to go if it's to compare with the proprietary apps available for Windoze or Mac.  Might be a bit of overkill for the typical tapers needs but you may want to also check out Ardour (ardour.org).

[homer420]

Nice to see you here homer.  I saw your page when you posted to oade a long time back and used some of that when I still worked in 16-bit.

Does wavebreaker handle 24-bit files yet?

Not officially however pigiron noted earlier in the thread that he's hacked 24-bit ALSA support into wavbreaker.  And thus I've requested he send me a patch so I can add it to my packages an begin playing around w/ it.  If all seems good I'll work w/ the author to get it integrated into future versions.

pigiron - feel free to just send me the source for your hacked version and I'll generate the patch ...

[Brian Skalinder]

Translating between int and float creates noise because rounding errors are introduced during the storage format conversion.  Try reading a 2G file into audacity and then writing it out to another file name.   You will rarely get an exact duplicate.

I have yet to figure out how to get audacity to stay in 24-bit int mode even though there is a setting that seems to be intended for that purpose.

Sorry, I'm not making myself clear.  My main qualifying question regarding this statement...

Most Linux audio tools don't do 24 bit well.  They quietly convert to 32 bit and back to 24, introducing noise.

...was:  At what point does this conversion to 32-bit and back to 24-bit take place?  Under what circumstances?  If we're talking during a simple file save, for example, then yeah - I understand how rounding errors would prove problematic.  But if the transformation from 24 > 32-bit and back only takes place during editing, then my follow-up question still stands:  is the suggestion that <1> using 32-bits for more precise math during editing and then dithering back to 24-bits noisier than <2> performing the editing with less precision in 24-bit and without dither?

Not sure if that's any clearer...   

[chase]

while this is a nice resource, unfortunately, it doesnt tackle the main problem with Linux recording...configuring the interface driver.

even on the ALSA page, many cards that are "supported" arent, at least the digital I/O portion of the interface isnt supported.
take the M-Audio PCI cards for example...sure, the Envy24 chip is supported, if you only use the analog RCA I/O. it's been the case for at least the last 6 years and that is IF you manage to get ALSA to load the driver in the first place (I've tried with 2.6.x kernels and I still cant get ALSA to load correctly...)

those of you who use Linux to transfer digital recordings, what interface are you using?

I have an M-Audio Revolution 7.1 which uses the Envy24 chipset and it has been detected and loaded properly in SuSE 9.2, 9.3, 10.0, and ubuntu.  They all seem to suffer from the same mixer problem though.  Whenever it loads, the left channel is always muted, although this can be easily fixed by opening your mixer of choice and bumping the levels to take it off mute.

[Brian Skalinder]

Translating between int and float creates noise because rounding errors are introduced during the storage format conversion.  Try reading a 2G file into audacity and then writing it out to another file name.   You will rarely get an exact duplicate.

Bingo!  [snip]

Okay, I think I get this now - in the process of simply reading and then re-writing a 24-bit WAV file, with no editing, Audacity is not bit-transparent since it (behind the scenes) converts the 24-bit file to 32-bits and then back again to 24.

This all got me curious, so I just installed and fired up Audacity 1.2.4 on Windows 2000 SP4.  FWIW, after changing the output format to 24-bit (from the default of 32bf), opening a 24-bit file in Audacity and exporting (saving) to 24-bit WAV has proven bit-transparent every time I've done it (about half a dozen, so far).  I wonder if the latest version has solved the problems you've experienced, FL, or if something fundamentally different is happening behind the scenes in the Win version v. the Linux version.

At any rate, FL, sounds like you've banged your head against that wall plenty in the past, and I don't blame you for bailing - I, too, would much rather record and listen than dork around with computer config stuff constantly!

[homer420]

In response to the other suggestion, aplay/arecord don't have any design features to prevent audio interruptions due to other system activity. ecasound does.  For that reason, the alsa team recommends against using aplay for live recording. ecasound is also extremely well supported by the author.

Correct, arecord/aplay do not have this capability built-in, however the Linux OS does provide ways to accomplish this.  You can change a processes scheduling priority by envoking it using the nice command.  In the 2.6 kernel there's multiple I/O schedulers available, for which the deadline scheduler provides near real-time behavior.  And since arecord/aplay are command line apps you can boot into say runlevel 2, which would prevent most system services from starting/running.  You could even customize runlevel 4 to be a "live recording" runlevel which only starts services absolutely necessary to do recording.

FWIW I have been using arecord for DAT to HD transfers for over 2 years now and have yet to run into any interupt or scheduling related problems.  Admittedly I have yet to use it for live recording purposes, however I don't see how this would really change things in terms of the kernel scheduler and interupts ...

[it-goes-to-eleven]

Correct, arecord/aplay do not have this capability built-in, however the Linux OS does provide ways to accomplish this.  You can change a processes scheduling priority by envoking it using the nice command.  In the 2.6 kernel there's multiple I/O schedulers available, for which the deadline scheduler provides near real-time behavior.  And since arecord/aplay are command line apps you can boot into say runlevel 2, which would prevent most system services from starting/running.  You could even customize runlevel 4 to be a "live recording" runlevel which only starts services absolutely necessary to do recording.

Another reason I avoided arecord was lack of support. I recall that the authors strongly suggested using a refined tool and that they wouldn't waste time supporting these types of issues.  Kai's support of ecasound is Amazing. I've written apps that use alsa to do data acquisition and I really wanted something more refined than that for live recording.

I did do a lot of work to optimize my linux laptop rig - power consumption, scheduler testing, low latency kernel, text only.  I had it setup to automatically start recording when powered on (if the minime was present).  It worked quite well. But I still didn't like the hassle of a laptop at shows.  I thought about building a dedicated headless recorder..

At some point I reminded myself that all the tweaking and optimization - exactly what you mention above - had nothing to do with recording live music. And it was a lot too close to work. So I wimped out, bought a 722 and started doing 15 shows a month 

[Lil Kim Jong-Il]

Okay, I think I get this now - in the process of simply reading and then re-writing a 24-bit WAV file, with no editing, Audacity is not bit-transparent since it (behind the scenes) converts the 24-bit file to 32-bits and then back again to 24.

This all got me curious, so I just installed and fired up Audacity 1.2.4 on Windows 2000 SP4.  FWIW, after changing the output format to 24-bit (from the default of 32bf), opening a 24-bit file in Audacity and exporting (saving) to 24-bit WAV has proven bit-transparent every time I've done it (about half a dozen, so far).  I wonder if the latest version has solved the problems you've experienced, FL, or if something fundamentally different is happening behind the scenes in the Win version v. the Linux version.

I've done tests in which Audacity read in a large file and wrote out an identical copy.  But in many other cases it didn't.   Someone posted about this a while back on their Windows machine and when I ran tests on my Linux machine, I got perfect copies so I made a wise crack about windows.   Now I've proven that I don't always get perfect copies and it's the same revision of Audacity I was using for the successful tests.  Sometimes I get a perfect copy until well into the file and then there are small errors.   

If you want to use audacity to resample and dither, then it's a decent program.  It just isn't capable of non-destructive editing.  From what I've seen of the traffic on the audacity user's list, we're so far beyond the intended user segment that I don't think they will do anything to fix it.  I couldn't even get anyone to respond to my posts about this issue.   I am running 1.2.3 so maybe I'll try 1.2.4 and report back.  I have files handy that have demonstrated this problem.


A very annoying thing about these errors is that what I'm assuming are rounding errors are not simply off by 1 as I would expect.  Sometimes the values are off by as much as 4.   I never bothered to use the file offset to calculate the byte position, I just always assumed it was the LSB.   If the errors were in the middle or MSB I would think that would show in the display and I never saw anything when I examined the waveform or listened.

I keep attributing these errors to rounding however after a beers worth of thinking I'm not sure that is correct.  The format for 32-float is: 1 bit sign indication, 8 bit exponent and 23 bit mantissa.  So a 24 bit integer value should convert to float and back with no issue.  Where you should get into rounding errors is when trying to represent integer values greater than 24-bits or real numbers that cannot be accurately represented in a 23-bit mantissa.  So while I tend to blame the errors on the 24int/32fl conversions, I'm not really sure that is the culprit.   Anyone have thoughts about this?  I haven't done any real CS stuff in a long time.

[it-goes-to-eleven]

Kai thought the simple 24>32>24 case should be accurate but I've found cases in ecasound where it isn't.  He suggested using libsndfile (an easy work-around in ecasound). It was more accurate but still not perfect. He attributed it to rounding/truncation.

Some applications will use libsndfile for doing conversions and audio file I/O.  Or.. If libsndfile is not available at compile time, they'll use their own internal routines (which have less functionality).

I'm also on the audacity list.. It isn't very active and people have trouble getting help. I agree that the typical user is far removed from our requirements.

[homer420]

I did do a lot of work to optimize my linux laptop rig - power consumption, scheduler testing, low latency kernel, text only.  I had it setup to automatically start recording when powered on (if the minime was present).  It worked quite well. But I still didn't like the hassle of a laptop at shows.  I thought about building a dedicated headless recorder..

At some point I reminded myself that all the tweaking and optimization - exactly what you mention above - had nothing to do with recording live music. And it was a lot too close to work. So I wimped out, bought a 722 and started doing 15 shows a month 

Completely understood.  I started going down the same path with the laptop but decided quickly having a laptop at a crowded bar gig wasn't for me. And thus I still record to DAT for much the same reasons

However I needed to break my dependence on windoze and M$.  So I set off to find linux apps which provided the same (simple) functionality I used for transferring DAT's to HD, splitting tracks, and burning CD's.  For high-end audio work linux is definitely lagging behind.  But it certainly does the trick for the basic functions I required, which is really what the Taper's Linux HOWTO is geared towards - tapers looking to move to linux for doing the standard transfer-split-burn type activities ...

Thanks again for yours and everybody elses feedback on this thread.  It's great to be part of this community 

[pigiron]

Not officially however pigiron noted earlier in the thread that he's hacked 24-bit ALSA support into wavbreaker.  And thus I've requested he send me a patch so I can add it to my packages an begin playing around w/ it.  If all seems good I'll work w/ the author to get it integrated into future versions.

pigiron - feel free to just send me the source for your hacked version and I'll generate the patch ...

Sorry... I have a habit of disappearing sometimes... if you find me, show me the way home 

Patch sent via email.

Damn interesting discussion go'n on here... that's what I like about having the source code... you can actually see what the sucker's doing... and if ya don't like it, fire up the compiler.

[pigiron]

forgot to mention...

i run a headless linux jukebox for playback... so i hacked flac123 to handle 24 bits if anyone's interested in a lightweight command line flac player that's seamless between tracks... works great for the stuff we record.

[it-goes-to-eleven]

I'd like to check out your flac123 mods.. It is a bit frustrating that a lot of these tools won't do 24, let alone 24/96..  I also use headless Linux for playback (even gave a headless linux music server to my folks one year ago.. still going strong!). I'm currently using the Slimdevices squeezebox but need to get 24/96 support in the new listening room. I have an idea on how to "easily" add the support to squeezebox.

[MattD]

I have an idea on how to "easily" add the support to squeezebox.

I'd be interested in hearing this.

[mfisch]

forgot to mention...

i run a headless linux jukebox for playback... so i hacked flac123 to handle 24 bits if anyone's interested in a lightweight command line flac player that's seamless between tracks... works great for the stuff we record.

Let me know when it will compile on PPC =)

[pigiron]

I'd like to check out your flac123 mods.. It is a bit frustrating that a lot of these tools won't do 24, let alone 24/96..  I also use headless Linux for playback (even gave a headless linux music server to my folks one year ago.. still going strong!). I'm currently using the Slimdevices squeezebox but need to get 24/96 support in the new listening room. I have an idea on how to "easily" add the support to squeezebox.

yep, know the frustration, but don't forget that this stuff's coming from a bunch of overworked/hung-over nerds doing it for fun/love... but I'll tell ya... if you get that SB working and you'll be a hero for a lot of folks!

The flac123 patch is so short, I'll try to attach it to this reply.

Here's the link to the original source code:  http://flac-tools.sourceforge.net/

now... undocumented (of course) usage... just go into a directory containing a bunch of flacs and enter "flac123 *flac" and off it goes... Ctl-c to skip to the next file... Ctl-c two or twelve quick times to prematurely exit. It has a "remote" mode for a frontend app... but that's a whole other thread.

And to mfisch...

Let me know when it will compile on PPC =)

brother!!!  I sling a bunch of PPC code... don't have access to a Mac... but I can get it compiling on one of these http://www-03.ibm.com/servers/eserver/pseries/hardware/highend/ ... will that do? 

seriously tho... i see that flac123's been tested on Mac OS 10.3.9 .... so if ya wanna give it a spin...


Sorry Dave... didn't mean to hijack the thread... now back to our regularly scheduled program, already in progress...

[mfisch]

And to mfisch...

Let me know when it will compile on PPC =)

brother!!!  I sling a bunch of PPC code... don't have access to a Mac... but I can get it compiling on one of these http://www-03.ibm.com/servers/eserver/pseries/hardware/highend/ ... will that do? 

seriously tho... i see that flac123's been tested on Mac OS 10.3.9 .... so if ya wanna give it a spin...


Sorry Dave... didn't mean to hijack the thread... now back to our regularly scheduled program, already in progress...

[/quote]

I'll give that a whack on Tiger this weekend ... I havnt compiled anything on mac yet =)
guh, you guys know theres no gui flac player for mac? maybe I'll learn xcode this weekend too.

[MattD]

There are GUI FLAC players for OSX. However, none of them that I know use Core Audio, so they can't play back FLAC files greater than 16/44.1 over hardware that supports the higher resolution files. There isn't even a command line player that I know of. There is a command line wave(/aiff?) player bundled in the Core Audio dev tools called "aplayer." It's written in C++ and can play back up to whatever resolution your Core Audio hardware supports.

I have given up trying to add FLAC support to that but it would be the perfect starting point for someone who knows what they're doing. The GUI is the relatively easy part once the command line version exists.

[mfisch]

There must be some working aiff/wave player .... you dont think something as simple as a pipe would work? I assume you tried this already ....

[nic]

There are GUI FLAC players for OSX.

but none of them play gaplessly...

[homer420]

For those interested I've added 24-bit support into my drecord script ... enjoy

[Lil Kim Jong-Il]

This all got me curious, so I just installed and fired up Audacity 1.2.4 on Windows 2000 SP4.

Just built 1.2.4 and ran a test.   It's still not bit perfect for me.  Here's a sample of what I get when comparing the original and exported files
 .
 .
 526601073 303 304
 526601079 340 341
 526601085 110 111
 526601091  27  30
 526601097  11  12
 526601103 174 175
 526601109 350 351
 526601115 230 231
 .
 .

I'm curious to know your preference settings and the command flow you used to get an exact duplicate.  Maybe it's operator error on my part.