Unoffical empeg BBS

Quick Links: Empeg FAQ | RioCar.Org | Hijack | BigDisk Builder | jEmplode | emphatic
Repairs: Repairs

Topic Options
#85916 - 07/04/2002 16:28 Problems with flac - to - lame
grgcombs
addict

Registered: 03/07/2001
Posts: 663
Loc: Dallas, TX
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
_________________________

Top
#85917 - 07/04/2002 16:52 Re: Problems with flac - to - lame [Re: grgcombs]
wfaulk
carpal tunnel

Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
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?
_________________________
Bitt Faulk

Top
#85918 - 07/04/2002 19:30 Re: Problems with flac - to - lame [Re: wfaulk]
grgcombs
addict

Registered: 03/07/2001
Posts: 663
Loc: Dallas, TX
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
_________________________

Top
#85919 - 08/04/2002 01:54 Re: Problems with flac - to - lame [Re: grgcombs]
Roger
carpal tunnel

Registered: 18/01/2000
Posts: 5683
Loc: London, UK
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?
_________________________
-- roger

Top
#85920 - 08/04/2002 07:58 Re: Problems with flac - to - lame [Re: Roger]
grgcombs
addict

Registered: 03/07/2001
Posts: 663
Loc: Dallas, TX
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
_________________________

Top
#85921 - 08/04/2002 09:23 Re: Problems with flac - to - lame [Re: grgcombs]
Roger
carpal tunnel

Registered: 18/01/2000
Posts: 5683
Loc: London, UK
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?
_________________________
-- roger

Top
#85922 - 08/04/2002 12:27 Re: Problems with flac - to - lame [Re: Roger]
grgcombs
addict

Registered: 03/07/2001
Posts: 663
Loc: Dallas, TX
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
_________________________

Top
#85923 - 08/04/2002 12:31 Re: Problems with flac - to - lame [Re: grgcombs]
wfaulk
carpal tunnel

Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
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.
_________________________
Bitt Faulk

Top
#85924 - 08/04/2002 12:33 Re: Problems with flac - to - lame [Re: wfaulk]
grgcombs
addict

Registered: 03/07/2001
Posts: 663
Loc: Dallas, TX
When will they learn???

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

Greg
_________________________

Top
#85925 - 08/04/2002 12:35 Re: Problems with flac - to - lame [Re: wfaulk]
grgcombs
addict

Registered: 03/07/2001
Posts: 663
Loc: Dallas, TX
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
_________________________

Top
#85926 - 08/04/2002 12:38 Re: Problems with flac - to - lame [Re: grgcombs]
wfaulk
carpal tunnel

Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
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.
_________________________
Bitt Faulk

Top
#85927 - 08/04/2002 13:09 Re: Problems with flac - to - lame [Re: wfaulk]
grgcombs
addict

Registered: 03/07/2001
Posts: 663
Loc: Dallas, TX
Recompiling flac and lame with GCC 3.0.4 didn't seem to make a difference.

Greg
_________________________

Top
#85928 - 08/04/2002 13:25 Re: Problems with flac - to - lame [Re: grgcombs]
wfaulk
carpal tunnel

Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
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?
_________________________
Bitt Faulk

Top
#85929 - 08/04/2002 13:51 Re: Problems with flac - to - lame [Re: grgcombs]
grgcombs
addict

Registered: 03/07/2001
Posts: 663
Loc: Dallas, TX
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
_________________________

Top
#85930 - 08/04/2002 13:53 Re: Problems with flac - to - lame [Re: wfaulk]
grgcombs
addict

Registered: 03/07/2001
Posts: 663
Loc: Dallas, TX
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
_________________________

Top
#85931 - 08/04/2002 20:31 Recursive directory shell script problems [Re: wfaulk]
grgcombs
addict

Registered: 03/07/2001
Posts: 663
Loc: Dallas, TX
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
_________________________

Top
#85932 - 09/04/2002 00:33 Re: Recursive directory shell script problems [Re: grgcombs]
wfaulk
carpal tunnel

Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
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.
_________________________
Bitt Faulk

Top
#85933 - 09/04/2002 00:42 Re: Recursive directory shell script problems [Re: grgcombs]
mtempsch
pooh-bah

Registered: 02/06/2000
Posts: 1996
Loc: Gothenburg, Sweden
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


Edited by mtempsch (09/04/2002 00:44)
_________________________
/Michael

Top
#85934 - 09/04/2002 00:53 Re: Recursive directory shell script problems [Re: mtempsch]
wfaulk
carpal tunnel

Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
    Oops, beaten to it.
At least we both focused on the other's alternate suggestion.
_________________________
Bitt Faulk

Top
#85935 - 09/04/2002 06:03 Re: Recursive directory shell script problems [Re: wfaulk]
grgcombs
addict

Registered: 03/07/2001
Posts: 663
Loc: Dallas, TX
These look like great suggestions! I'll give both of them a try this afternoon. Thank you so much for your help guys!

Greg
_________________________

Top
#85936 - 09/04/2002 07:05 Re: Recursive directory shell script problems [Re: grgcombs]
smu
old hand

Registered: 30/07/2000
Posts: 879
Loc: Germany (Ruhrgebiet)
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
_________________________
proud owner of MkII 40GB & MkIIa 60GB both lit by God and HiJacked by Lord

Top
#85937 - 09/04/2002 14:33 Re: Recursive directory shell script problems [Re: smu]
wfaulk
carpal tunnel

Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
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.
_________________________
Bitt Faulk

Top