GNOME Bugzilla – Bug 361151
Freeze using suggested value for lame plugins
Last modified: 2006-10-25 05:55:13 UTC
Please describe the problem: As repoted by myself 361140 and confirmed by Tim-Philipp Müller, liblame don't seems to accept the option "bitrate=196". This value is the one suggested in Sound Juicer manual to setup the MP3 profile. It was changed from 192 (working) fixing bug 345305. Of course, 'cause the issue is related to liblame, all applications using MP3 profile will freeze (Rhythmbox do), not only Sound Juicer Steps to reproduce: 1. Edit MP3 profile using "bitrate=196" in pipeline 2. Put an Audio CD disc in drive 3. Open SJ or Rhythmbox and try to rip disk Actual results: The application freeze. Running in terminal using --gst-debug-level=2, you should have: ERROR lame gstlame.c:1058:gst_lame_setup:<enc> lame_init_params returned -1 WARN lame gstlame.c:496:gst_lame_sink_setcaps:<enc> error: could not initialize encoder (wrong parameters?) Expected results: Rip my CD :-) Does this happen every time? Only using "odd" values for bitrate (128 and 192 are OK, 191 no, 193 no, 127 no). Try using the test pipeline suggested by Tim-Philipp in bug 361140 comment 2 Other information: Please, change the help page, proposing the working pipeline and adding this info about wrong values for bitrate, then release a new version before people will start to report this issue again and again and again.
Created attachment 74561 [details] [review] fix (untested) Oops, the freeze-on-error might be my fault from a previous patch. This patch should hopefully fix it. Unfortunately I can't test the fix myself at the moment, since HAL in ubuntu edgy doesn't recognise my SCSI drives and passing the drive device with the --device parameter doesn't work either (aborts). Rationale for the changes: - The only reason to actually wait for the state change to PAUSED to complete was so we can query the current position and get the track start in seconds. This, however, isn't necessary any longer in GStreamer-0.10 anyway, because the CD sources now operate in a per-track mode anyway, so all tracks start at time 0 by default. Getting this start offset hence isn't required any longer, so we don't have to wait for the state change to complete any longer either. In the patch we now wait for a max. of half a second so immediate errors can be returned immediately (this isn't necessary, however, you could handle all errors asynchronously via the error_cb if you wanted to) - the _get_state (, NONE) was incorrectly used here, since _get_state() won't return if the error doesn't happen in the state change function, apps must watch for error messages on the bus for that (I was confusing how this works with a utility function used in another application, sorry).
Created attachment 74618 [details] Error dialog after applying patch Patch applied (by hand :-| I wasn't able to find any good -pX for it). SJ non longer freeze. This is the (poor) error message that appears using "wrong" bitrate.
> Patch applied (...). SJ non longer freeze. This is the (poor) error > message that appears using "wrong" bitrate. The indeed rather poor error message comes from GStreamer. This is something that needs fixing in GStreamer and is covered by bug #361140. Thanks for testing the patch!
Applied to CVS, and I also fixed the docs. Thanks!
*** Bug 364675 has been marked as a duplicate of this bug. ***