New user constructive feedback

[AaronShort]

First I'd like to say that this community has done an amazing job. With everything that you have accomplished you have every right to be proud.

I've gotten around to installing Rockbox and after fiddling with it for a while I'm heading back to iTunes/original firmware. Here's why. I'm a developer and I could spend the hours to fix some of these issues myself but I have far to many other projects. While the original firmware and iTunes are clunky and have their problems They work and work good enough with the minimum of fuss. Rockbox does have an amazing amount of polish but it also drops the ball on a few things.

The default user interaface and many of the downloadable themes are amazingly smooth and show off the power of rockbox however they also are tiny and hard to read at a quick glance.

Song management. My music collection is very well taged but it's also much larger than my ipod. It is far to large to go album by album everytime I want to change out music. I've setup playlists with my fav songs. The perscriped method is to use playlists to copy over the songs. I was able to get Amok to work though it didn't copy over my folder.jpg files. yes i know I could use mp3tag to recreate them. (from the embeded image tags) but I shouldn't have to. I know rockbox isn't a song manager but perhaps if you could team up with some open source one to better integrate. (songbird?) some pluging for winamp or foobar?

cover images. jpgs need to be supported. i use a windows box and maybe it's diff on diff platforms but over here .bmps aren't used for anything else. also the lack of resizing is frustrating.

I also played around with the custom menus. I wish there were ways to add multiple tags to the same parent menu. ie "Artist - Album".

I did love all the games but in the end I just need my ipod to work without requiring me to jump through so many hoops. Thanks for such a great piece of software and I'll check on it in the future.....

[Llorean]

It sounds like 3/4 of your complaint is "PC-side software doesn't exist to manage music on an MSC device well." Which, really, isn't something we can do something about. You can't make another open source project do anything, you can just file a feature request, and answer their questions.

Even the "jpeg images should be supported issue" is irrelevant, because a good PC application could convert them behind the scenes to bitmap and you'd never know.

As to "displaying 'Artist - Album'" I don't see anything from the DataBase wiki page on why you shouldn't be able to, so I'm confused about that. Is the information there inaccurate and in need of updating?

It sounds like it boils down to "one of your features isn't working" (or you weren't aware of it) and you don't resize images yet" in terms of things we can (or possibly, should) actually do anything about. Is that the gist of it?

[Chronon]

Yes, it does seem like most of the complaints revolve around PC-side software (or lack thereof).  Regarding syncing playlists, Amarok seems to do this already and plays nice with UMS devices.  I have not had any problem running a batch conversion utility to convert any folder.jpg files into cover.bmp's. 

I really don't see that much fuss, considering how many features it unlocks for me.  Oh, and regarding your distaste of themes -- it's a great reason to design your own!  (It looks like you have.  Thanks!)

[saratoga]

I would like to see jpeg supported, but not enough to figure out how the buffering code works.

[soap]

It sounds like 3/4 of your complaint is "PC-side software doesn't exist to manage music on an MSC device well."

In his defense, embedded appears to be the de facto standard for portable player album art, so finding a PC-side program which moves folder.jpgs is not likely to happen.

[Chronon]

Good point.  I haven't really been bothered by this much since my whole music collection isn't so much larger than my player and I can fairly easily just copy folders over to my player.

[soap]

Good point.  I haven't really been bothered by this much since my whole music collection isn't so much larger than my player and I can fairly easily just copy folders over to my player.

Yes, I too just move around entire folders, but I can imagine the problem of trying to use playlists to "automate" the process.  (and maintain albumart)

[Llorean]

But these are things users of Rockbox could go to other OSS projects and say "Hey guys, there's a lot of us now, and Rockbox is already open source so you don't have to reverse engineer anything, how about adding support for our players and the way they expect things?"

[audio-i]

Good point.  I haven't really been bothered by this much since my whole music collection isn't so much larger than my player and I can fairly easily just copy folders over to my player.

Yes, I too just move around entire folders, but I can imagine the problem of trying to use playlists to "automate" the process.  (and maintain albumart)

Just for the record, the program the original poster mentions (Amok) copies files using playlists, preserving (or not) the folder structure, so it's great for that purpose (it's on the wiki now). And for album art, this album art extractor designed - I believe - for Rockbox, is a fantastic tool http://vcardenasblog.blogspot.com/2008/03/ipod-album-art-extracter-for-rockbox.html (on the wiki too) Edit: ... album art extracter is for ipods. Irfanview can easily batch covert .jpg's to .bmp's specifying new file name, size, etc

[saratoga]

I would like to see some official stance on how things like JPEG support, resizing, embedded album art should be implemented (or if they are unacceptable a statement to that effect).  It might encourage people to work on them.

[Llorean]

I think "embedded album art" is more or less just waiting on some final decision about jpeg-in-the-core, which probably needs someone to figure out how much (or little) it'll hurt binsize (especially for low memory targets).

As to resizing, it's been discussed to no end with it most often (but not always) settling as "wanted, but it should resize on load/buffering so that it's small in-memory and use as little memory during resizing as possible"  I believe. I think some work is already being done on this, but you never know how that'll turn out.

[saratoga]

So a patch that decoded JPEG files on the fly, resized them, and then stored them as BMPs in the audio buffer would be acceptable?  Assuming of course that it was done at reasonable RAM cost of course.

How about an embedded?  I suppose that should work the same?  Is it expected that the art be removed from teh tag during buffering as well?

[Llorean]

Decoding JPEG files and resizing them should be separate (as we don't want to remove support for the existing bitmaps, and they should be resizable in the end too). But yeah, I'm almost certain it would be acceptable.

As for embedded I would expect that the decoding to LCD format and resizing should happen during buffering so that what's on the buffer is raw and ready for use in the WPS, and I would expect you wouldn't also keep the original compressed data around. I'm not sure what other people expect, but the impression I got is similar: Any decoding/resizing should happen during the loading of the image.

[shotofadds]

I'd recommend MediaMonkey as an excellent music management tool for Windows - it can sync to MSC devices just as well as MTP ones, and can copy over your folder.jpgs (or extract embedded art if necessary) during the sync process.

It's then a relatively simple step to run one of the existing album art conversion tools over the contents of player. A MediaMonkey plugin might already exist to do this, or if not, one could be written relatively easily.

Even so, I do think our album art support could use some "usability" improvements. For me, resizable .jpg support would be the "ideal" usability winner, and I think it's well worth a chunk of extra RAM/binsize (at least on high-memory targets).

Of course, the real barrier is finding an interested developer with the time to spend implementing these things....