I'm having a little difficulty getting lame to encode vbr mp3's from flac compressed files.

It looks like this:
flac -c -d something.flac | lame -v - something.mp3

The errors look like this:
Internal buffer inconsistency. flushbits <> RevSizebit reservoir error: [And some omitted data]

Anyone have some info on how to get rid of these errors?
Greg

I assume that it works fine if you do:

flac -c -d something.flac > something.wav

lame -v - something.mp3 < something.wav

It's possible that lame might be doing a multipass encoding. Anyone know if that's the case? If so, then you'll have to disable the multipass (which could affect quality) or write to a temporary file (as above). (I don't think this is really the case now that I think about it some more.)

Hmmm. I just did it on my MacOS X machine using flac v.1.0.2 and lame v.3.89 with no problems. What OS are you using? Is it possible that stdout and stderr are getting combined somewhere? Maybe try giving a `-s' to flac?

Running Redhat 7.2, yeah flac seems to output wavs just fine. Adding -s to flac doesn't seem to make a difference though ... when i break it out, I'm decoding into a temp wav file, as you're doing, and it looks fine. When I run lame by itself, I get the same old error blasting through.

When I run it with -b 192 instead of -v , (using cbr instead of vbr), it seems to work fine. Why won't vbr work if cbr does?

Incedentally, I'm using the same flac and lame version that you are.

Greg

It worked fine for me with those versions if I used --vbr-new, rather than -v. I wonder if there's a problem in the old VBR encoder that means it doesn't work properly on piped input?

Even without pulling from stdin or writing to stdout, I still get errors, with --vbr-new ... here's my most recent command line

lame --vbr-new "Sunday Girl.wav" "Sunday Girl.mp3"

I still get errors like the following:
Internal buffer inconsistency. flushbits <> ResvSizebit reservoir error:
l3_side->main_data_begin: 368
Resvoir size: 376
resv drain (post) 2
resv drain (pre) 0
header and sideinfo: 288
data bits: 3004
total bits: 3294 (remainder: 6)
bitsperframe: 2920

Is it possible cdparanoia is to blame with the orignal ripping? My options there were:

cdparanoia -qw $track $tmpwav .. nothing too crazy here.

g

Some brief poking about on mailing list archives suggests that memory corruption could be the cause. This is down to overclocking, buggy compiler, or bad memory.

Where did you get your lame binary from?

Compiled from 3.89 sources, using GCC 2.96 that came with Redhat 7.2...

maybe I'll see if I can find a precompiled binary somewhere and try that one...

This machine isn't overclocked. As for the memory, I guess it could be bad, but this is the only problem I've seen come up in many months.

I'll try a precompiled binary and see what happens.
Greg

Wasn't GCC 2.96 the version that RedHat cooked up that wasn't really released by the GCC guys that broke a million and one things? (Just looked. It is.) Try getting a copy of 2.95.3 or something else that the GCC folks actually released.

When will they learn???

Actually when will I learn? I've been burned by this same thing a thousand times already last year...

Greg

What do you think about GCC 3.0.x? Is it more hassel than it's worth, should I just downgrade to 2.95.3?

Greg

I've not yet used a 3.x GCC. I think I've been out of a job long enough that they were actually released after I became unemployed. Regardless, I think that either way you go will be better than where you are now.

Recompiling flac and lame with GCC 3.0.4 didn't seem to make a difference.

Greg

Hmmm.

You said that using an intermediate file to store the wav file that you got from decoding the flac file didn't help, right? Do you have another wav file, one that wasn't decoded from a flac file, that you can test to see if it's a problem with lame or with its input?

Ok, you need to drop the optimization down to -O1 in order for it to compile on practically any compiler but 3.0.2

Greg

Fixed this problem by changing compiler optimizatinos for lame ... works great now, thanks for your help Bitt, you got me pointed in the right direction with the compiler info.

g

Bitt, or anyone in the know on shell scripts, i'm hoping one of you guys can assist me with some issues I'm having with a shell script.

I want to run an executable on each and every flac file in a given directory (including sub-directories). My problem is in the generation of the for/do loop.

for i in `find $1 -name '*.flac' -print` ; do \
echo $i; done

This script pukes on directories/files with spaces and other odd characters in the name. Evidently the "for" loop will look for a space in a line, and assume it's a new item.

is there any way to escape the directory/file names in the find so it doesn't puke on the for?

Greg

Assuming you're using GNU utilities, you can do something similar like this:

find $1 -name '*.flac' -print0 | xargs -0 echo

The ``-print0'' option to find tells it to separate its output with null characters instead of spaces, and the ``-0'' option to xargs tells it to expect input separated by null characters. It'll, unfortunately, be a pain to incorporate that into a script. The easiest thing to do would be to then call a new script from xargs, but that will add shell startup time.

Ooh! Here's an idea. Reset IFS to the null character (same as Ctrl-@) and then use find's ``-print0'':

OLD_IFS=$IFS

IFS="^@"

for i in `find $1 -name '*.flac' -print0`; do

  echo $i

done

IFS=$OLD_IFS

Whatever you call instead of echo might depend on IFS being set to something more sane, though, so you might need to reset it before calling it. You might also need to find some way of getting that null character into IFS without embedding the binary 0x00. Some ideas include

IFS=`echo "x\c" | tr x \\000`

or

IFS=`printf "\000"`

You could also try using perl. I have the feeling it might be a little more forgiving than a Korn-type shell.

You could probably do it with the -exec {} stuff for find or pipe the
strings through sed to replace all instances of ' ' (space) with '\ '
(backslash+space). xargs may be something to play with too.

I find the resulting command line too hard to read and too error prone to do it
interactively on the command line though...

I'd make a little perl script, something like this:

#!/usr/bin/perl



@files = `find $ARGV[0] -name '*.flac' -print`;



foreach $file (@files) {

    chomp $file; #get rid of trailing newline

    $file=~s/ /\\ /g; #substitute any spaces with backslash+space to please the next command line

#you may want to do further processing of the filename here...

    `cp $file $file.backup`; #or do whatever you really want

}

Edit: Oops, beaten to it. Oh well...
/Michael

Oops, beaten to it.

At least we both focused on the other's alternate suggestion.

These look like great suggestions! I'll give both of them a try this afternoon. Thank you so much for your help guys!

Greg

Just a note on the -exec parameter of find:

It is really simple once you get the hang of it:
specify the find command line like you would do normally, for example:

find . -name \*.mp3 -type f

to find all files in or below the current directory that are name *.mp3
Now, append -exec to it, followed by the full commandline you want to execute. Replace any occurence of the filename that will be passed to it with \{\}, for example:

find . -name \*.mp3 -type f -exec mv \{\} test/\{\}

Finally, append \; to it.

find . -name \*.mp3 -type f -exec mv \{\} test/\{\} \;

Done.
The commandline for your

for i in `find $1 -name '*.flac' -print` ; do \ 

echo $i; done

would look like this:

find $1 -name '*.flac' -exec echo \{\} \;

cu,
sven

Keep in mind that -exec will only allow you to run one process per found item. Also note that it will start exactly one process per item, which could be good or bad, depending on context. Using xargs will still only allow you to run one process per found item, but you can get it to combine multiple found items into one process. (For example, xargs would be good for using cat, but -exec would be better for using mv.)

Note that ``one process'' above does not mean that that process couldn't run other processes, but that would incur even more overhead.