Need a music player app
|Status:||Closed||Start date:||11 Nov 2014|
|Category:||04 - Applications|
|Target version:||1.1.0 - Upgrades|
|Severity:||01 - Critical|
- Directory/File name
- Artist's Name
- Album name
The top level list shows one of these three and the user selects and drills down to find the music of interest.
It requires a playlist to be configurable and can be saved and reloaded.
It should display the current album cover and title being played.
This all means it needs to be able to read ID3 tags from mp3's and have a directory for album covers.
If I can find a lightweight player (one that easily cross-compiles on PiBox) I may use that, otherwise we may have to write one.
RM #396: Initial import of early-stage music player app (or it's early stage framework at least).
RM #396: Add full navigation support for artists and albums with a stub for listing album track titles.
RM #396: Sort album tracks and display them in a monospace font so that the track numbers and
titles are properly aligned.
RM #396: Disable dbtop setting in default configuration file. Fallback to defaults in code.
RM #396: Add getopt to db generator script. Add sections (functions, initialization, main, etc.). Add option to support setting directory to scan.
RM #396: Add example config that runs vlc instead of omxplayer, which can be used for testing on build host.
RM #396: Ignore data/musicfe.cfg so we can use it for testing without actually checking it in.
RM #396: Properly handle setting the dbTop and support multiple musiclib directories.
RM #396: Add support for both GDK_KEY_<arrow> and GDK_KEY_KP_<arrow>. Fix off-by-one malloc that locked up on Pi but not on Intel desktops. Fix use of default image path for album.png if not using -T option.
#4 Updated by Hammel over 4 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
#8 Updated by Hammel about 1 year ago
Here is a way to extract id3 info from mp3s using exiftool:
exiftool file.mp3 | egrep "Artist|Album|Title"
The problem is that this is a perl script and the module it belongs to is not specifically defined by Buildroot, though it may be possible to get it as a custom module. Alternatives to this include id3v2 or eyeD3. id3v2 only requires the idv3lib and is C code but it's output is not line oriented, making it harder to parse (but not impossible). It seems the best fit though it doesn't appear id3lib is included in Buildroot, re: I'd have to build both as a combined third party package.
Note that I simply need a way to create a DB for music, like I do with videos (via VideoLib and VideoFE). The player can be omxplayer, which knows how to play mp3 files.
- Use ffprobe (part of ffmpeg) to extract metadata as JSON:
ffprobe -show_format -show_streams -print_format json <file> | jq .format.tags > <file>.json
- Use ffmpeg to extract the cover art for an individual file:
ffmpeg -i <file> <file>.png
- Set the root directory for music
- Find directories that contain music files.
- Create a .musicdb in that directory.
- Run ffmpeg to gen cover art to .musicdb/coverart for each file as file.png
- Run ffprobe for each file and output to .musicdb/file.json
That's it. No Internet lookups required. We assume your music is already tagged.
Users can search for music by Album or Artist (based on contents of all metadata files).
Now audioFE just scans the root directory for .musicdb/coverart and displays the first image found for each. Selecting an image selects that directory and extracts track names. User can play all or select one. No playlists to start (feature to be added later). Cover art for each track is displayed while playing the music. ESC stops the music playing or exits. omxplayer plays the music files.
This may be easier than I thought. I can add the DB generation to VideoLib pretty easily. Finding directories with music in them might be harder, maybe.
- % Done changed from 10 to 20
Created new repo under Pibox project on GitLab. Pushed current code base to it. Code can now parse the db files, provides a selection of Album or Artist and shows a carousel of album art for both. Left and Right keys allow moving through the carousel.
Next up is to implement selection handling. In Album db hitting Enter on an album will show the available tracks and provide the playback options. In Artist db hitting enter shows the album carousel but only for the selected artist.Playback options:
- Show tracks (possibly sorted by album track number, if available)
- Up/Down moves through track list.
- Selecting active track plays it.
- Tab changes to playback settings:
- Auto play (play rest of tracks in list)
- ESC returns to carousel mode.
- % Done changed from 20 to 70
App is written and works fine on a build host (my laptop). It presents a carousel of artists and albums and a list of tracks to play that can be selected using up/down keys and ENTER to play (TAB changes mode from PLAY to STOP). It's possible to start playing a track, then select and play another one (even from another album) without first stopping the one that's playing. But to stop the playing track you either exit the app or change to STOP mode and hit ENTER again. Kinda cool that this is all written in Cairo and Pango.
There is one bug: Need to reset track index when leaving track mode so that choosing another album will start at the first track entry.
The test on the build host used vlc to play audio. Support for changing audio levels up/down should be added since that can be done by sending keys using a FIFO.
Still need to test this on the RPi. I need to create a USB stick with music that the app can browse and play.
Preparing test on RPi, I constructed my music databases (two of them) on a USB stick and tested on my desktop (bigger than my laptop). It exposed some bugs in how I find the files. Those were fixed and the changes pushed.
On the RPi the app comes up but fails to start because it can't find the default album.png image. This is in data/album.png in the source tree and appears to be hard coded in the source - I thought I made that configurable with the -T option but must have missed something. Anyway, on the RPi that file can't be found because it's actually in /usr/share/musicfe.
Once I fix that I think the app will start properly. Then I can see if it plays music and, probably more importantly, how responsive it is.
- % Done changed from 70 to 80
Fixed that bug, plus a couple others I uncovered while testing on real hardware. All were pretty minor and easy to track down.
App works fine on hardware. It's a little sluggish on an RPi 2. Strange thing: I accidentally built for RPi1 (Pi Zero) and the binary worked fine for an RPi1, even with a different toolchain. Not much performance difference when compiled with the RPi2 toolchain. Both worked fine.
Haven't tested on RPi3 yet.
Still need to add new app to meta build. After I do that (and probably test on a RPi3, just for performance differences) then I'm done with this issue.