GNOME Bugzilla – Bug 112622
Sound Juicer should write out an M3U file
Last modified: 2021-05-17 15:46:50 UTC
It would be really cool if SJ could write optionally write out a .m3u file for the cd that had just been ripped.
Created attachment 36691 [details] [review] The patch display a dialog to determine whether to create the playlist file(m3u). the playlist file is created in the home directory. the playlist file has the album name.
Comment on attachment 36691 [details] [review] The patch display a dialog to determine whether to create the playlist file(m3u). the playlist file is created in the home directory. the playlist file has the album name. This is how I see this working: There is a check box in the preferences dialog so that people are not prompted every time they rip an album. This check box defaults to no. The m3u file is written to the base path and is named "artist-album.m3u"
Created attachment 36962 [details] [review] I have added a checkbox with label "Create Playlist after Extracting " in preference dialog.. and the check box defaults to no and the m3u file is written to base path and is named "album-artist.m3u "
Created attachment 37090 [details] [review] This is a modified patch which creates a additional key "playlist" in Gconf and uses it as reference. The patch is tested and works well
I'll implement a plugin architecture for 2.16 I hope, this code can go there.
May i ask what did happen to this featurerequest? I would love to see this feature. To be exact: This feature prevents me from switching from grip to juicer.
Any status update on this feature request? With Grip no longer supported in many GNU/Linux distributions I find myself looking for a replacement CD ripper. So far Sound Juicer comes the closest to meeting my needs, but it does not create a .m3u playlist file. A request for this functionality can also be found in Ubuntu's Launchpad: Sound Jucier should build playlists https://bugs.launchpad.net/ubuntu/+source/sound-juicer/+bug/540657
I made a set of patches that implement this feature. The user can enable this feature with a new setting on the preferences dialog. The playlist is stored in the "Music Folder" and is named from the album artist and title. The "Strip special characters" setting is taken into account. If a playlist with the same name already exists, the new tracks are appended to it. The playlist format is Extended M3U (http://en.wikipedia.org/wiki/M3U). The paths in the M3U file are relative to the playlist location. Technically, this patch is a bit different from the previous submission: - GIO is used for generating the M3U file. The file is generated in a single operation. This is consistent with the rest of SJ. - The code used for generating the m3u file is on its own file (sj-playlist.c), so that there is "minimal intrusion" in sj-extracting.c. If a plugin system is ever implemented in SJ, the changes necessary should be rather minimal (Except of course for the UI and GConf part). - Error handling is implemented. The patches will follow. I would be glad to make any changes that you'll think is necessary.
Created attachment 232942 [details] [review] Move the pattern handling code into it's own file. This code will be used by the playlist generation feature.
Created attachment 232943 [details] [review] Implement the playlist generation feature As described in my previous comment.
Oh yes, two more things: These patches apply to HEAD. For testing them by running SJ from the src folder, you need to add a "create_playlist" boolean entry in GConf or else the application will crash on launch. This will not happen if the SJ is installed with make install, since the schema is updated by the patch.
Created attachment 232947 [details] [review] Implement the playlist generation feature Just a bit of code cleanup over the previous version of the patch (else statements did not respect the code style of the rest of SJ).
Not sure what Ross wants, but I would say that it should be using totem-pl-parser to generate the playlist instead, so that XSPF would be supported as well.
Using a maintained library instead of replicating code seems like a good move, so yes please use totem-pl-parser.
Created attachment 233352 [details] [review] Implement the playlist generation feature using totem-pl-parser Attached is a new version of the patch which uses totem-pl-parser (tested with version 3.4.3) for generating the playlists. The user can now select the format of the playlist on the Preferences dialog. All the playlist formats supported by totem-pl-parser are available. The value of this setting is stored in a new playlist_format GConf key (string). Don't forget to manually add it if running SJ from the source code tree. I noticed that m3u files generated by totem-pl-parser seem to miss the track duration in the #EXTINF line. I took a look on the code, and effectively, this information is not added into the file. Not sure if it's normal and maybe I'll create a bug report for this, but that's another issue. This version of the patch doesn't append new songs to an existing playlist. Instead the user is prompted to confirm if he wants to replace it. I could parse the existing playlist with totem-pl-parser and append the new tracks on it. The thing is that they may be some other metadata on the existing playlist that is not parsed (or at least saved) by totem-pl-parser. I prefer not to overwrite this data without the users permission. I could eventually modify the warning message so that the user could choose if he want to append to or to replace the existing playlist. Some feedback about this would be nice.
Created attachment 233353 [details] [review] Move the pattern handling code into it's own file (take 2). When I submitted my first patch I forgot that my git.diff.renames config value was set to "copies". The previous version considered that the sj-patterns.h file was a copy of the sj-prefs.h file (which isn't entirely false, but).
Created attachment 233359 [details] [review] Implement the playlist generation feature using totem-pl-parser Fixed some typos in comments. Sorry for spamming.
(In reply to comment #15) > This version of the patch doesn't append new songs to an existing playlist. > Instead the user is prompted to confirm if he wants to replace it. > I could parse the existing playlist with totem-pl-parser and append the new > tracks on it. The thing is that they may be some other metadata on the existing > playlist that is not parsed (or at least saved) by totem-pl-parser. > I prefer not to overwrite this data without the users permission. > I could eventually modify the warning message so that the user could choose if > he want to append to or to replace the existing playlist. > Some feedback about this would be nice. Having sound juicer write playlists would be great. I think that the option to add tracks would be very useful. If you think about albums with more than one disc, they either need a separate playlist for each disc with the disc number prefixed to the filename and appended to the playlist title so you can tell them apart or the new tracks need to be added to the existing playlist in the right order (so if I rip disc 2 before disc 1 I still end up with track 1 disc 1 as the first track in the playlist.)
Phillip, I am willing to take a look at your suggestion, but first I would like to have some sort of confirmation on whether is it really worth to spend time on it. Does Sound Juicer has some future within GNOME 3, or with all the new apps being developed (e.g. Music) will it slowly become abandon-ware and it's better to focus on this new apps? Ross, Bastien, any comments?
(In reply to comment #19) > Phillip, I am willing to take a look at your suggestion, but first I would like > to have some sort of confirmation on whether is it really worth to spend time > on it. > > Does Sound Juicer has some future within GNOME 3, or with all the new apps > being developed (e.g. Music) will it slowly become abandon-ware and it's better > to focus on this new apps? > > Ross, Bastien, any comments? Hi Nuno, Just prefixing the filenames with the disc number shouldn't be much work at all, rewriting the list would be more. My thoughts for what there worth are that if people keep working on sound juicer then it will keep going. The roadmap for Music at https://live.gnome.org/Music makes no mention of ripping CD's as far as I can see so sound-juicer would complement it well. As more people by music by downloading it I guess there will be less need for sound-juicer but CD's aren't going away any time soon. Having playlist support would be a great addition to sound-juicer.
Created attachment 256699 [details] [review] I have updated Nuno's patch to apply on top the wip/gsettings branch. This first patch prepares the way for creating playlist files using existing functions in sound-juicer rather than cutting and pasting code as in the previous patch.
Created attachment 256705 [details] [review] This is a reworked version of Nuno's patch with the following changes Never strip special characters from playlist title. Separate playlist for each disc in multi-disc albums. Playlist saved in same directory as ripped tracks. Overwrite dialog follows HIG better.
Created attachment 256706 [details] [review] I've rewritten the preferences UI and settings code to use gsettings and property binding. The UI now has a separate section for playlist settings rather than lumping them in with the device settings.
Created attachment 256708 [details] Screenshot of preferences dialog with playlist settings.
Hmm, bug #311688 was suggesting doing this through a plugin, but the plugin work never happened :(
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/sound-juicer/-/issues/21.