GNOME Bugzilla – Bug 791961
can't rip files at more than 112 kbs
Last modified: 2017-12-30 11:48:27 UTC
the title pretty much explains everything but i will give you some informations to better understanding i am a fedora user and in fedora i need to install codecs via terminal or software center, and that generally covers all codecs except gst-ugly and gst-bad-nonfree now, ripping discs via rhythmbox was working well and 192 kbs selection in mp3/ogg/opus/m4a was resulting in a 192 kbs file, but i needed to install gst-ugly because sound-converter needed that to convert mp3, and after having installed that, every ripped disc in lossy format results in 112 kbs. Tried doing a clean install where everything worked fine until i reinstalled gst-ugly and files were 112 kbs again, so i assume there's should be some conflict with that... had a look on gstreamer presets in the .local folder but everything seems to be fine... any help?
That sounds like a bug which should be reported against rhythmbox first, while installing new plugins means these new plugins may be used over previously installed ones, it is still up to the application to deal with that and configure them appropriately, help would be easier to provide if you can figure out and share the gstreamer pipelines that are set up by rhythmbox in both cases.
already reported to rhythmbox devs, but now i can't find it and it's not in my list of bugs, and anyway i had no responde pretty much like in the ask fedora community don't think it's a rhythmbox issue but more of a general one since it happens even with clementine and sound-juicer and it happens from when i've installed gst-ugly (removing it does not solve the problem) if you could give me an advice on how to check those gstreamer pipelines i can report those :)
(In reply to luca from comment #2) > (removing it does not solve the problem) Erg, that does make the issue even weirder > if you could give me an advice on how to check those gstreamer pipelines i > can report those :) GStreamer offers API (eg [1]) to dump pipelines as dot graphs, if the application you are using uses that API, you can simply run it with the GST_DEBUG_DUMP_DOT_DIR environment variable set to a path, eg with: GST_DEBUG_DUMP_DOT_DIR=$PWD rhythmbox , you should find dot files in your current directory, which you can then transform to svg with dot -Tsvg example.dot -o example.svg . If the application you use does not use that API however, you will need to get its sources and patch it to do so I'm afraid. [1]: https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstInfo.html#GST-DEBUG-BIN-TO-DOT-FILE:CAPS
> don't think it's a rhythmbox issue but more of a general one since it > happens even with clementine and sound-juicer Also, as far as I know sound-juicer does not use gstreamer, correct ? Perhaps installing -ugly caused a newer version of cdparanoia to be installed?
Sound juicer uses GStreamer.
(In reply to Tim-Philipp Müller from comment #5) > Sound juicer uses GStreamer. Ah, noted
i runt your command and after entering the library with rhythmbox i got some error, but they were related to some files in general so i thought they were not worth reporting, anyway i ripped a song with ogg 192 kbs preset and the result was 112 kbs as always...debug gave me lots of dot files which will append on here as requested...
Created attachment 365991 [details] svg file for debug
Created attachment 365992 [details] all svg files for debugging
That's unfortunately only from the discoverer run (when checking your input files), not from the encoding itself. Can you maybe make such an encoded file available? With Vorbis you generally have variable bitrate files (unless you artificially constrain it, which Rhythmbox does not seem to do and which can hurt quality), and if your input material does not require the target bitrate for a specific quality, the output might also use a lower bitrate.
i'll attach here even the errors i've got when i just opened rhythmbox with the debug option and i will attach the encoded song :) anyway ogg is just an example because i get the same exact result for m4a, opus and mp3. I don't know how rhythmbox encode files but i do know that prior to installing the gst-ugly package, ripping at 192 kbs resulted in 192 kbs (or whatever set quality), now they all are 112 (exept for wma in clementine which seems to be 128) so i assumed there's should be some conflict somewhere with codecs...
Created attachment 366003 [details] that's the encoded file rhythmbox has 2 encoding setting which are default and and the one with the slider to decide kbs, here the slider was at 192 but 112 is the output
Created attachment 366004 [details] svg files for debugging these are the svg files for debugging (the ones when you enter the program, and not while ripping) they may be helpful
This file was indeed encoded with a nominal bitrate of 112kb/s (and no upper/lower limit set) and is ~113kb/s. So the encoder was configured for exactly that instead of any other value. I couldn't find how the encoding profile stuff is done in rhythmbox with diving deeper into the code, but this all suggests a bug in Rhythmbox in any case and possibly the same in sound-juicer. Can you run with GST_DEBUG=6 GST_DEBUG_COLOR=no and redirect stderr to a log file, and then compress that and attach/upload it somewhere? It's going to be a huge file though. Also only do a single encode so there's not too much noise :) The SVG files are similarly useless as last time, they are from the discovery/inspection of existing files and not from the encoding itself.
hi there, thanks for the info...executed your command while ripped and really lots of things showed up. Unfortunately i don't know how to put all those informations on a log file, so i need some help in that... for the meantime i'll attach all the informations i've been able to catch up, they might have something useful...
Created attachment 366028 [details] gst command partial output
You can redirect to a file with "> /path/to/file 2>&1" at the end of command, or use the GST_DEBUG_FILE=/path/to/file at the beginning of the command. Anyway, after seeing these logs which only showed discovery logs, I had a quick look at rhythmbox, and as it turns out its burn feature is implemented by invoking brasero as a subprocess, and passes NULL as the environment to g_spawn_async, which means you will want to reproduce in brasero and get the gstreamer logs there.
brasero was not installed, now is installed, and launched with proper command, but how to proceed now?maybe i should select a 1:1 copy and see terminal output?because i can't find any way to rip a disc with brasero...
(In reply to luca from comment #18) > brasero was not installed, now is installed That's surprising, as your logs don't show gstreamer being used beyond discovery, and the only instances of "burn" in rhythmbox's source code are found in https://github.com/GNOME/rhythmbox/blob/master/plugins/brasero-disc-recorder/rb-disc-recorder-plugin.c , which pretty clearly uses brasero :)
(In reply to luca from comment #18) > because i can't find any way to rip a disc with brasero... That also is surprising, as it's pretty much the main purpose of the program (https://wiki.gnome.org/Apps/Brasero)
Gaah, rip != burn my bad, I should learn reading some day
as far as i know (but of course i might be wrong) rhythmbox uses brasero for burning playlists and sound-juicer for ripping records... anyway i created a cue audio file via brasero and terminal showed me lot of things, but unfortunately i always get an empty file as a log...is there a specific format for logs?
> anyway i created a cue audio file via brasero and terminal showed me lot of > things, but unfortunately i always get an empty file as a log...is there a > specific format for logs? Forget about brasero, I got confused for a minute there, it shouldn't have anything to do with your problem here. Have you tried obtaining logs with soundjuicer? As I said in my comment earlier, you can redirect to a file by calling eg: GST_DEBUG=6 soundjuicer > logs.txt 2>&1
so, i finally have that sound-juicer log file...i'll attach the file on the attachments :)
Created attachment 366031 [details] sound-juicer log file
It seems like sound-juicer is just not setting any preset at all: 0:00:54.256707034 [331m 2382[00m 0x55e89675a460 [37mDEBUG [00m [00m encodebin gstencodebin.c:922:_create_element_and_set_preset:[00m Creating element from factory vorbisenc (preset factory name: (null) preset name: (null)) And I don't see any code that manually sets the bitrate anywhere. This should actually produce a VBR file, not like the one you attached. But the default settings should give something around 112kb/s on most input.
Both rhythmbox and sound-juicer seem to share some code and the way how the encoding profiles work though. So that's probably why both are misbehaving. I'll reassign this to rhythmbox for the time being, this doesn't look like anything going wrong in GStreamer so far. Just settings not being done by the Rhythmbox/SJ code.
so what should i do?open a bug about rhythmbox?
oh, already assigned...hope we'll sove this one as it's rather tedious...
You also reported bug 779723 about this. Has anything changed since then?
not a single thing unfortunately...as of now the only solution is to do a clean install and not install gst-ugly then...
Not exactly a satisfying solution, I was hoping rhythmbox / sound juicer devs could help you figure out what pipeline is set up after you have picked a 192 kbps bitrate, why presets don't seem to be applied to it, and why the chosen bitrate does not seem to be set on the encoding elements
Setting status back to NEW after the bug has been reassigned
yep, and anyway 192 and ogg are just examples because the same applies to mp3/m4a/opus and whatever bitrate choosen...anyway as Jonathan Matthew pointed out i already opened another bug post about that but we didn't find any solution so far...
*** This bug has been marked as a duplicate of bug 779723 ***
Hey, why are you closing this as a duplicate of another closed issue? There seems to be a legitimate issue here, which I assumed rhythmbox devs would be able to help in investigating further.
I'm closing this as a duplicate of another bug because it's the same bug filed by the same person about the same issue.
Well I guess the question then is why did you close the other bug in the first place, as far as I can tell there must be a problem somewhere if the user selects a constant bitrate and ends up with a variable bitrate file, right?
In bug 779723, we established that the encoder was producing files at roughly the requested bit rate. It seems like current encoders still vary the bitrate a bit even when a specific bitrate is requested. I'm not really interested in looking into it past that point.
That's not the problem here though. Of course Vorbis is always variable bitrate, but what happens is that the user sets 192kb/s in the rhythmbox settings, but the output is ~112kb/s. And this only seems to happen after the user installed gst-plugins-ugly, which is completely unrelated to this other than possibly installing a few more presets (but for unrelated elements). And it seems like rhythmbox is not setting any preset at all on the encodebin and it also seems like no bitrate is set (or at least I couldn't find any code in rhythmbox that sets a bitrate manually), which is probably not what the rhythmbox code is supposed to do. There seems to be something wrong with how rhythmbox is setting encoding profiles and presets There clearly seems a but somewhere, and it looks like it is in the code that selects what encoding profile and preset is to be used.
just some toughts...considering prior to installing gst-ugly everything was working as expected there is clearly a bug somewhere in sound-juicer or rhythmbox. of course there are workarounds like ripping in lossless and then convert to lossy, but why i need to use a workaround when there is an easy solution that is supposed to work?and what if it happens to a lot more people that just doesn't know how to report things?i may be the only one having this bug but to me is in the interest of the community to solve it...
(In reply to Sebastian Dröge (slomo) from comment #40) > That's not the problem here though. Of course Vorbis is always variable > bitrate, but what happens is that the user sets 192kb/s in the rhythmbox > settings, but the output is ~112kb/s. And this only seems to happen after > the user installed gst-plugins-ugly, which is completely unrelated to this > other than possibly installing a few more presets (but for unrelated > elements). > > And it seems like rhythmbox is not setting any preset at all on the > encodebin and it also seems like no bitrate is set (or at least I couldn't > find any code in rhythmbox that sets a bitrate manually), which is probably > not what the rhythmbox code is supposed to do. There seems to be something > wrong with how rhythmbox is setting encoding profiles and presets Here's the code: https://git.gnome.org/browse/rhythmbox/tree/shell/rb-track-transfer-batch.c#n719 rb_gst_encoding_profile_set_preset finds the audio profile and applies a preset to it. I'm pretty interested to hear about the bug in this code that causes it to break when some extra unrelated presets are installed.