Topic: 24 bit wavbreaker (linux content)

[pigiron]

I guess I don't believe in planning ahead, so it was only after the gear arrived that does 24/96 that I tried to figure out how to poke and prod the files it creates on the linux box.

I'd been happy with wavbreaker for busting up a show, so I spent some (a lot of) hours mashing it around until it could handle these new monsters. So... if you want a copy of the source code without experiencing the joy of DIY    PM me with your email addy and I can send it... in RPM format... for SuSE, but you should be able to change it for other distro's (except for maybe debian)  Oh, and the file is 137600 bytes, so hopefully your ISP won't barf on it.

But here's the caveats... only got it working for ALSA, didn't even attempt the OSS mod... I haven't tested it yet on x86_64, only i586... the method wavbreaker uses to keep track of the time is kind of strange, so the time elements are a little off (I think I saw it show something like an extra 10 seconds over a 2G file)... and it probably needs to be beat a little more to verify I didn't break 16 bits, but I think that part's still humming... let's just say, this thing's beta.

But it seems to do the main functions... plays and shows a 24 bit file, and busts it up on sector boundaries.

[MattD]

If they have a CVS, you should contribute your version there.

[it-goes-to-eleven]

Way to go on the 24bit hack

I was just checking out the new release of wavbreaker, 0.8... It wouldn't build due to some gtk issues. When I forced the issue by taking unsound measures, I found that it apparently still does not support 24 bit

I've also had pretty bad audio buffering issues with wavbreaker in the past so I haven't been able to use it as an alternative to cdwave (alsa > ua5 ).

The project is now hosted at sourceforge with cvs.

[pigiron]

EDIT:  THERE'S A NEWER PATCH BELOW

after languishing, seems to have been a sudden flurry of activity on the code... it must have a new owner

thanks for the pointer... I grabbed the new 0.8 version and it has some nice new features (it's about time... I had previously hacked some of those for my own personal amusement).

so, I just now merged my 24 bit hack into version 0.8... but I only took it to the point that it's good enough for me... you may feel differently.

• wavbreaker calculates (wall clock) time in such a way that my hack causes it to be off for 24 bit files (but it still works fine for 16 bit files)... so don't trust the displayed track times... nor the times in any TOC file you create... but this should will not affect busting up a concert unless you base your splits on time instead of your ears.
• 24 bit support is ALSA only... I did the OSS hack, but apparently => version 4.0 of OSS is required for 24 bit support... so this change is commented out so it would compile on my boxes with my older versions of OSS... see the linuxaudio.c  change if you want to turn it back on.
• the newer versions added a "feature"... if the audio file does not have an extension of ".wav", it's treated as a CDDA file and hardcodes it's format (16/44100) without sanity checking to determine if it really is or not... I thought this was dangerous... so I turned it off, and it will now throw an error if the file doesn't end with ".wav".
• haven't yet tested the disk splits when using "etree" file naming... but hey... we're talking 24 bits here.

on the good side, the new merge and offset text file features still seem to work after my twiddling.

patch file attached... further tweaking is greatly appreciated 

[it-goes-to-eleven]

Thanks!  Patch applied with no issues.. 

I've had some trouble building 0.8 on my primary desktop due to some gtk issue with gtk_file_chooser_set_do_overwrite_confirmation.. but that's nothing a little judicious commenting can't fix more easily than a big gtk upgrade

24/96 files come up and display just fine...

Playback takes about 2 seconds to start.  I guess I'll have to look at the buffer sizes and see what the problem is with that.

wavbreaker definitely has some workflow gotchas that trip up my cdwave-centric habits..  In cdwave, I stop and start playback with the space bar (not present in wb). In cdwave during playback, clicking anywhere in the waveform jumps to that point.  So I'll let playback go and keep clicking at the right edge of the window to skip ahead. That allows me to look and listen for indications of a song end. That's more necessary when song endings are difficult to pinpoint.

Haven't had a chance to really look at the code yet..

[pigiron]

I've had some trouble building 0.8 on my primary desktop due to some gtk issue with gtk_file_chooser_set_do_overwrite_confirmation.. but that's nothing a little judicious commenting can't fix more easily than a big gtk upgrade

we like it when you talk dirty 

Playback takes about 2 seconds to start.  I guess I'll have to look at the buffer sizes and see what the problem is with that.

yea... haven't seen that with the 3 boxes I use... even when running remotely with wireless... so guessing some ALSA tweaking may be in order.   ahhh... the joys of linux 

wavbreaker definitely has some workflow gotchas that trip up my cdwave-centric habits..  In cdwave, I stop and start playback with the space bar (not present in wb). In cdwave during playback, clicking anywhere in the waveform jumps to that point.  So I'll let playback go and keep clicking at the right edge of the window to skip ahead. That allows me to look and listen for indications of a song end. That's more necessary when song endings are difficult to pinpoint.

good idea!  didn't even think of trying that!

[pigiron]

nothing like sharing crappy hacks to get one embarrased into improvements 

rolled up the sleeves and got a true understanding of how this program keeps track of time... so here's a (hopefully) better hack.

The time should now be correct for popular sample frequencies... 44.1, 48, 88.2, 96, and 192 K... both 16 and 24 bits... fire up your calculator and plug in the following numbers to check if some other freq will be correct:

   ((bits / 8 ) * channels * freq) / 75

If the answer is an integer (i.e. there's no fraction) it should be good to go.

That crazy formula allowed me to not completely gut the original program, while still preventing SBE's on 16/44100.

------------------

PLUS... now that it can tell time    I added another tweak... you can import a TOC file.

This means that you can take your 24 bit show (at any of the above freqs), copy it to CD quality, then bust up either one into tracks... and if you export the TOC file, you can import it to automagicly get those same track breaks on the other.

that is, if you can get wavbreaker to eat that complete huge ass 24 bit file     This wasn't something that their "offset file" method allowed.

------------------

Since you can now put a filename on the command line, I spent a chuck of time twiddling to get it to puff on a pipe so it would eat a FLAC file... something like  flac -dc x.flac | wavbreaker -  but only met with partial success so far.

------------------

oh... I turned their CDDA file usage back on... but you've been warned   try something like this to see what I mean:

     /usr/bin/wavebreaker   /usr/bin/wavbreaker

anyway... here it is if you feel dangerous... use it on the original 0.8v tarball... i.e.  the one on sourceforge.