View previous topic :: View next topic |
Author |
Message |
Skippy204 Guru
Joined: 09 May 2008 Posts: 339 Location: Colorado, USA
|
Posted: Thu Dec 20, 2012 3:40 pm Post subject: encoding with lame [solved] - grip was the problem |
|
|
I use grip to rip CDs, lame to encode. My thought is that this is a lame problem, not a grip problem - but I could be wrong.
I rip a CD, everything rips and encodes fine - then suddenly the encoded files are not encoding any more. The output mp3 file will be a file that is exactly 2176 bytes in size and upon investigation is in fact the ID3 tags. The actual audio content is simply gone....
lame-3.99.5 currently installed.
If ripping a CD of 10 tracks, the first 3 may be normal, then 4 that are only the tags, then 2 normal, then the last one is only the tags.
I've been using the same setting in grip for years.
Code: |
encoder command line: -h -b %b %w %m
|
Strange and annoying...?
I tried encoding some wav files to mp3 from the command line and it worked, but I'm not sure that tells me much since even via grip sometimes it works, sometimes it doesn't. So far I've not been able to figure out some common factor about all the times it doesn't work.
Suggestions on how to proceed with identifying the problem? Thank you.
Last edited by Skippy204 on Sat Feb 23, 2013 5:20 pm; edited 1 time in total |
|
Back to top |
|
|
audiodef Watchman
Joined: 06 Jul 2005 Posts: 6639 Location: The soundosphere
|
|
Back to top |
|
|
wcg Guru
Joined: 06 Jan 2009 Posts: 588
|
Posted: Fri Dec 21, 2012 6:44 pm Post subject: |
|
|
strace?
Code: |
mv /usr/bin/lame /usr/bin/lame.bin
|
Make a script to replace it in a text editor:
Code: |
#!/bin/bash
# strace script for lame
exec strace [strace args] -o strace_lame_`date '+%d_%M_%S'`.log /usr/bin/lame.bin "$@"
|
Name the script "lame" and copy it to /usr/bin, so that grip will
run it where it would normally run lame.
There are lots of options to strace (man strace), you will probably
only need a few of them. That log would probably end up in
the current working directory with that command, feel free to direct
it to your home directory, /var/log, or elsewhere by prepending
an absolute path to the basename of the log file.
That will tell what system calls lame is making when it processes
those tracks or files. I just did a quick scan of the strace man page,
I did not see an option for telling it to append to the log file. That
embedded date command in the log file name should separate
the log files sufficiently if grip calls lame individually for each
different track on a ripped cd so that you can tell them apart.
If the problem is a system call that lame is making that is
failing, that should find it. (Don't forget to move the script
somewhere and move /usr/bin/lame.bin back to /usr/bin/lame
when you figure it out.) _________________ TIA |
|
Back to top |
|
|
wcg Guru
Joined: 06 Jan 2009 Posts: 588
|
Posted: Sat Dec 22, 2012 11:17 pm Post subject: |
|
|
PS:
The "exec strace ..." in that script should be all one line, not word-wrapped (if
you need two lines, continue it with "\" at the end of the first one).
If the log is not coherent (because grip is passing tracks to lame in batches,
for example), you can change it to redirect stdout and stderr to the same
file descriptor and use a shell interpreter ">>" to append each instance
of straced output to the same log file.
Code: |
#!/bin/bash
(strace [strace args] /usr/bin/lame.bin "$@") 2>&1 >> [path to]/strace_lame_`date '+%Y_%m_%d'`.log
|
(Again all one line. Those log files will simply be dated with "year_month_day",
so you can easily tell when they are from when you happen upon them several
weeks, months, or years later. The previous version, with the "-o logfile" option,
dated them with "year_minute_second" to make successive log files not overwrite
the logs from previous tracks when lame is converting several in succession with
grip calling lame individually for each track.) _________________ TIA |
|
Back to top |
|
|
Skippy204 Guru
Joined: 09 May 2008 Posts: 339 Location: Colorado, USA
|
Posted: Sun Dec 23, 2012 4:28 pm Post subject: |
|
|
Howdy, thanks for the strace suggestion. I'm doing something wrong tho.
I created the bash script, renamed lame, and it works - but I'm not getting the log files where I expect them to be.
My first bash script looks like this
Code: |
#!/bin/bash
(strace -ciTv /usr/bin/lame.bin "$@") 2>&1 >> /home/skippy/mp3/strace_lame_`date '+%Y_%m_%d'`.log
|
files are such
Code: |
/usr/bin
root # ls lam* -l
-rwxr-xr-x 1 root root 112 Dec 23 08:55 lame
-rwxr-xr-x 1 root root 89440 Nov 19 03:37 lame.bin
|
I'm expecting to see the log files in /home/skippy/mp3/ but nothing is happening. Lame is being called. The directory does exist. What am I missing? Thanks. |
|
Back to top |
|
|
wcg Guru
Joined: 06 Jan 2009 Posts: 588
|
Posted: Tue Dec 25, 2012 1:14 am Post subject: |
|
|
I have no idea. That script looks ok to me. I just looked at the strace man
page again, it says "strace [strace args] command [command args]", more
or less. "$@" expands to the args to command, in this case lame.bin.
Maybe grip is piping to lame's stdin and strace is not picking that up?
Two things to try:
[code]
echo "hello world" >> /home/skippy/mp3/testdir
(strace [strace args] /usr/bin/lame.bin [lame args] < some_file.wav) 2>&1 >> test_strace.log
[code]
The first command simply insures that you have write permission for
the directory where you expect the log files to end up.
The second command tests whether strace will trace input piped to its stdin
and pass that input onto the command that it is tracing. If that does not work,
then you need to find a file that lame fails on and strace that. (Which would
take an indeterminate amount of time since lame does not fail on every
track.)
One interesting thing to find out is if it fails on the same tracks on the same
cds if you have grip run it over again on that cd. Then if you rip those tracks
individually, does lame also fail on those tracks piped to it without grip
as an intermediary. (If you can find one track that lame always fails on, no
matter how it is called, you have input that can use to strace lame even if
strace fails on piped input.)
edit:
Another thing that you could try if strace fails to pass stdin on to
the traced process is to strace grip itself with the same sort of
wrapper, using the -f or -ff options to strace. (I assume that the
trace of the lame child process of grip will end up in the same
log with the -f option to strace.) _________________ TIA |
|
Back to top |
|
|
Skippy204 Guru
Joined: 09 May 2008 Posts: 339 Location: Colorado, USA
|
Posted: Wed Jan 02, 2013 4:35 pm Post subject: |
|
|
Thanks for the suggestions.
First I'll address your questions. There is not any certain CD or track that it fails with. I'm 100% sure it's not a CD issue. Typically how this goes is like so...
I'll be ripping tracks and everything is working correctly. Then it starts creating the files that only have the tags and no audio and all subsequent tracks are like that. I reboot the computer and start over, it works fine until some point where it starts creating the mp3 files without audio again.
My first theory was that some other process was running that was somehow interfering with the encoding process. I always blame Firefox and/or flash player when anything goes wrong. I love Firefox but it's sooooo high maintenance. Anyhow, I tried ripping CDs making sure not to start Firefox. Still started getting the mp3 files with no audio. I've also tried it while doing nothing else with the computer at all. So it's not any program I'm starting.
I can not discount it isn't some background process.
But then as I tested more instead of simply rebooting as soon as the errors started to occur I found cases where I would get correctly encoded mp3 files after the mp3 files without audio.
Back to rebooting - after I reboot I can put the same CD that gave me the empty tracks in, rip it, and get tracks with audio.
That's a long winded way of saying it's not the CD.
Now, on to your latest suggestions.
I do have access to the directory.
Code: |
Wed Jan 02 08:47
~/mp3
skippy $ echo "hello world" >> /home/skippy/mp3/testdir
Wed Jan 02 08:48
~/mp3
skippy $ ls
daniel_bor dean_koontz steve_hackett testdir
Wed Jan 02 08:48
~/mp3
skippy $ cat testdir
hello world
|
Then I tested your second suggestion and things got interesting.
Code: |
Wed Jan 02 08:52
~/mp3/daniel_bor/the_ravenous_brain__disk_01
skippy $ (strace -ciTv /usr/bin/lame.bin track_01.wav) 2>&1 >> test_strace.log
LAME 3.99.5 64bits (http://lame.sf.net)
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding track_01.wav to track_01.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
18313/18313 (100%)| 0:11/ 0:11| 0:12/ 0:12| 42.260x| 0:00
----------------------------------------------------------------------------------------------------------------------------------------------
kbps MS % long switch short %
128.0 100.0 62.8 12.9 24.3
Writing LAME Tag...done
ReplayGain: -1.4dB
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
87.85 0.000094 0 38939 read
12.15 0.000013 0 2242 write
0.00 0.000000 0 14 open
0.00 0.000000 0 14 close
0.00 0.000000 0 2 1 stat
0.00 0.000000 0 15 fstat
0.00 0.000000 0 16 lseek
0.00 0.000000 0 36 mmap
0.00 0.000000 0 22 mprotect
0.00 0.000000 0 5 munmap
0.00 0.000000 0 4 brk
0.00 0.000000 0 4 1 ioctl
0.00 0.000000 0 2 1 access
0.00 0.000000 0 1 execve
0.00 0.000000 0 187 times
0.00 0.000000 0 1 arch_prctl
------ ----------- ----------- --------- --------- ----------------
100.00 0.000107 41504 3 total
Wed Jan 02 08:53
~/mp3/daniel_bor/the_ravenous_brain__disk_01
skippy $ lls
total 562660
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:43 01-track_01.mp3
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:44 02-track_02.mp3
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:44 03-track_03.mp3
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:45 04-track_04.mp3
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:45 05-track_05.mp3
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:46 06-track_06.mp3
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:46 07-track_07.mp3
-rw-r--r-- 1 skippy skippy 0 Jan 2 08:51 test_strace.log
-rw-r--r-- 1 skippy skippy 7654503 Jan 2 08:53 track_01.mp3
-rw-r--r-- 1 skippy skippy 84378044 Jan 2 08:50 track_01.wav
-rw-r--r-- 1 skippy skippy 79264796 Jan 2 08:51 track_02.wav
-rw-r--r-- 1 skippy skippy 93868364 Jan 2 08:51 track_03.wav
-rw-r--r-- 1 skippy skippy 99016892 Jan 2 08:52 track_04.wav
-rw-r--r-- 1 skippy skippy 105872972 Jan 2 08:52 track_05.wav
-rw-r--r-- 1 skippy skippy 105459020 Jan 2 08:53 track_06.wav
|
Here is what you see above.
The wav files were all ripped by grip.
The first 7 mp3 files were generated by grip and do not contain any audio information, only the tags.
The file track_01.mp3 was generated at the command line, after the 7 mp3 files that have no audio, and that one does have the audio in it
I did it again, changing the command line to more accurately replicate the command line as passed from grip and got the same result. A valid mp3 file. I deleted track_01.mp3 and a new one is created below.
Code: |
Wed Jan 02 09:19
~/mp3/daniel_bor/the_ravenous_brain__disk_01
skippy $ (strace -ciTv /usr/bin/lame.bin -h -b 128 track_01.wav) 2>&1 >> test_strace.log
LAME 3.99.5 64bits (http://lame.sf.net)
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding track_01.wav to track_01.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
18313/18313 (100%)| 0:22/ 0:22| 0:23/ 0:23| 21.252x| 0:00
----------------------------------------------------------------------------------------------------------------------------------------------
kbps MS % long switch short %
128.0 100.0 62.8 12.9 24.3
Writing LAME Tag...done
ReplayGain: -1.4dB
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
77.51 0.000255 0 2242 write
22.49 0.000074 0 38939 read
0.00 0.000000 0 14 open
0.00 0.000000 0 14 close
0.00 0.000000 0 2 1 stat
0.00 0.000000 0 15 fstat
0.00 0.000000 0 16 lseek
0.00 0.000000 0 36 mmap
0.00 0.000000 0 22 mprotect
0.00 0.000000 0 5 munmap
0.00 0.000000 0 4 brk
0.00 0.000000 0 4 1 ioctl
0.00 0.000000 0 2 1 access
0.00 0.000000 0 1 execve
0.00 0.000000 0 187 times
0.00 0.000000 0 1 arch_prctl
------ ----------- ----------- --------- --------- ----------------
100.00 0.000329 41504 3 total
Wed Jan 02 09:20
~/mp3/daniel_bor/the_ravenous_brain__disk_01
skippy $ lls
total 562660
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:43 01-track_01.mp3
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:44 02-track_02.mp3
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:44 03-track_03.mp3
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:45 04-track_04.mp3
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:45 05-track_05.mp3
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:46 06-track_06.mp3
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:46 07-track_07.mp3
-rw-r--r-- 1 skippy skippy 0 Jan 2 08:51 test_strace.log
-rw-r--r-- 1 skippy skippy 7654503 Jan 2 09:20 track_01.mp3
-rw-r--r-- 1 skippy skippy 84378044 Jan 2 08:50 track_01.wav
-rw-r--r-- 1 skippy skippy 79264796 Jan 2 08:51 track_02.wav
-rw-r--r-- 1 skippy skippy 93868364 Jan 2 08:51 track_03.wav
-rw-r--r-- 1 skippy skippy 99016892 Jan 2 08:52 track_04.wav
-rw-r--r-- 1 skippy skippy 105872972 Jan 2 08:52 track_05.wav
-rw-r--r-- 1 skippy skippy 105459020 Jan 2 08:53 track_06.wav
|
And the log file from strace is being generated, but has no data. I expect as there are no errors this makes sense.
I repeated this process for the other wav files and got all good mp3 files.
Code: |
Wed Jan 02 09:29
~/mp3/daniel_bor/the_ravenous_brain__disk_01
skippy $ lls
total 605572
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:43 01-track_01.mp3
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:44 02-track_02.mp3
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:44 03-track_03.mp3
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:45 04-track_04.mp3
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:45 05-track_05.mp3
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:46 06-track_06.mp3
-rw-r--r-- 1 skippy skippy 2176 Jan 2 08:46 07-track_07.mp3
-rw-r--r-- 1 skippy skippy 0 Jan 2 08:51 test_strace.log
-rw-r--r-- 1 skippy skippy 7654503 Jan 2 09:20 track_01.mp3
-rw-r--r-- 1 skippy skippy 84378044 Jan 2 08:50 track_01.wav
-rw-r--r-- 1 skippy skippy 7190568 Jan 2 09:26 track_02.mp3
-rw-r--r-- 1 skippy skippy 79264796 Jan 2 08:51 track_02.wav
-rw-r--r-- 1 skippy skippy 8515081 Jan 2 09:27 track_03.mp3
-rw-r--r-- 1 skippy skippy 93868364 Jan 2 08:51 track_03.wav
-rw-r--r-- 1 skippy skippy 8982359 Jan 2 09:27 track_04.mp3
-rw-r--r-- 1 skippy skippy 99016892 Jan 2 08:52 track_04.wav
-rw-r--r-- 1 skippy skippy 9603865 Jan 2 09:28 track_05.mp3
-rw-r--r-- 1 skippy skippy 105872972 Jan 2 08:52 track_05.wav
-rw-r--r-- 1 skippy skippy 9566666 Jan 2 09:29 track_06.mp3
-rw-r--r-- 1 skippy skippy 105459020 Jan 2 08:53 track_06.wav
|
At this point I think I need to experiment more by encoding more from the command line and waiting for an error to occur.
I wanted to put all this information out there however in case I'm missing something.
Thank you again for your suggests so far. You've been very helpful. |
|
Back to top |
|
|
wcg Guru
Joined: 06 Jan 2009 Posts: 588
|
Posted: Fri Jan 04, 2013 2:09 pm Post subject: |
|
|
You are missing something. You have this:
Code: |
(strace -ciTv /usr/bin/lame.bin track_01.wav) 2>&1 >> test_strace.log
|
You need this to see if strace will pass stdin on to lame.bin:
Code: |
(strace -ciTv /usr/bin/lame.bin < track_01.wav) 2>&1 >> test_strace.log
|
There is a "<" redirection in between the end of the lame.bin args
and the name of the file, so that instead of lame.bin simply reading
the name of the file as an argument, it can only get to the file
if strace passes stdin on to lame.bin.
(lame also needs "-" as an argument to look for the input file
on stdin and another "-" to write to stdout, according to the lame
man page, so you may need to adjust a tracing script for that.)
Lame itself seems to be working fine when you pass it a file
as an argument. Do you get the same results if you do this?
Code: |
/usr/bin/lame.bin [args] - - < track_01.wav > track_01.out
|
That would test lame's stdin/stdout handling, but I expect that it
works. I would look at grip as the source of the error. It seems
like grip somehow gets a zero length for audio data where
the errors occur. Whether it stops reading the track too soon
and branches to its write routine or it somehow zeros out a
variable in error before beginning the write, I can't really guess.
You might need to trace grip with gdb to see what is really
happening. (stracing grip might give you an idea, though,
by comparing the system calls on a track where it does
write the audio data with the system calls on one where
the audio data is missing.) _________________ TIA |
|
Back to top |
|
|
Skippy204 Guru
Joined: 09 May 2008 Posts: 339 Location: Colorado, USA
|
Posted: Wed Feb 06, 2013 6:15 pm Post subject: |
|
|
Hi -
I've been off the net for a bit, just got back to this.
You are right, I did mess that up and left out the " < ". Good stuff.
So I did much more testing and had no problems like this with any other ripping program, only GRIP.
Then, it occurred to me to do something I should have tried 2 months ago. I deleted all the config files for grip in my home directory. Just ripped 4 CDs. Worked perfect.
And there it is. The simple solution works. If this turns out not to be the solution I'll post again, but I'm going out on a limb and gonna say that fixed it.
Thank you, again, for all your assistance. I appreciate you taking the time. |
|
Back to top |
|
|
wcg Guru
Joined: 06 Jan 2009 Posts: 588
|
Posted: Fri Feb 08, 2013 1:08 am Post subject: |
|
|
Cool. Do not forget to move lame.bin back to lame, etc:
Code: |
mv /usr/bin/lame ~/lame_strace.sh
chmod 644 ~/lame_strace.sh
mv /usr/bin/lame.bin /usr/bin/lame
|
_________________ TIA |
|
Back to top |
|
|
Skippy204 Guru
Joined: 09 May 2008 Posts: 339 Location: Colorado, USA
|
Posted: Sat Feb 23, 2013 5:19 pm Post subject: |
|
|
Yup, I've ripped more CDs. That fixed it. Not a single problem since deleting the config files.
Thanks for the reminder about the lame binary. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|