Support and General Use > Audio Playback, Database and Playlists
[Fixed] Clip+ vs. lengthy tag entries (esp. classical)
keyb_gr:
From what I've been able to gather, the Clip+ is a "low-mem" target and as such will only load a limited amount of metadata (what was it, like 300 bytes in total and up to 64 per entry?). In most cases, this has proven sufficient for me, except for one genre: classical. I am currently tagging according to ClassicalStyleGuide, which results in metadata as follows (usually I have ID3v2.3 + ID3v1):
Artist Name : AntonÃn Dvořák
(note to self: find developer of "Nimbus" font to increase the chances of a glyph for 'Å™' being added)
Track Title : Symphony No. 9 in E minor, op. 95 "From the New World" - III. Scherzo: Molto vivace
Album Title : Symphonies Nos. 8, 9 (Berliner Philharmoniker feat. conductor: Rafael Kubelik)
Date : 1966
Genre : Classical
Composer : AntonÃn Dvořák
Track Number : 07
<CONDUCTOR> : Rafael Kubelik
This is one of the problematic cases already. Both track and album title are truncated, in fact the roman numerals in the track title are not fully preserved, which is annoying. From what I can see, the total amount of data isn't that large, so I guess it's the per-entry limit that hits here.
Now I remember a recent discussion / bug report where someone had issues with a huge comment filling up all the memory, leaving no space for any "real" metadata. This would benefit from a limit to individual entry length.
I have no idea how to reconcile these cases, except by giving things a wee bit more memory to work with. I'd gladly part with a few hundred bytes of buffer memory, which is not too critical in a flash player like the Clip+ anyway.
I'm currently on r29711.
So, any opinions?
saratoga:
--- Quote from: keyb_gr on April 18, 2011, 01:02:35 PM ---From what I've been able to gather, the Clip+ is a "low-mem" target and as such will only load a limited amount of metadata (what was it, like 300 bytes in total and up to 64 per entry?).
--- End quote ---
Its not low memory, so it should be 900 bytes IIRC.
--- Quote from: keyb_gr on April 18, 2011, 01:02:35 PM ---I have no idea how to reconcile these cases, except by giving things a wee bit more memory to work with. I'd gladly part with a few hundred bytes of buffer memory, which is not too critical in a flash player like the Clip+ anyway.
--- End quote ---
You're welcome to give your self as much RAM as you like. The limits were introduced in this commit:
http://svn.rockbox.org/viewvc.cgi?view=rev;revision=29174
Feel free to change them.
keyb_gr:
Believe it or not, I did it. Even as a computer science redneck with a sub-GHz "dev box" running Windiows 2000 (gasp!), I did find an old version of VirtualBox that could be persuaded to install and run so I could set up the Ubuntu disk image and stuff within. It's kinda slugtastic (I left cross-compiler setup running overnight, so no idea how many hours that took, and a Rockbox compile seems to take like half an hour or so), but works.
I upped the limits to 1800 / 600 and 600 / 300 now (total / item), which are very unlikely to interfere in practice. rockbox-info.txt says RAM usage is up by 4672 bytes, and buffer size is down from 5.73 to 5.72 megs. I can live with that.
The default values are rather tight IMO. Something that's as crucial to user experience as tag display should be given a bit higher priority. It wouldn't need to be as luxurious as my first shot, but something like 900 / 300 and 300 / 120 should still work pretty well while keeping rogue comments in check.
EDIT: I just noticed that my modified build has Replaygain and resume not working. (An unmodified one compiled earlier works fine.)
W. T. F. ?!
EDIT^2: Nevermind, seems I need to keep the binary and codecs in sync. Makes sense.
gbl08ma:
Not really related to the topic, but running Ubuntu in VirtualBox on a computer with less than 1GHz of CPU and then compile Rockbox inside it is not a good idea at all - that's why it is taking half an hour, and I'm still surprised, as it should took long, even if you never compiled Rockbox before.
I'd say you'd be much better making a partition on the HD of the PC and install Ubuntu (or perhaps another lighter Linux distro) there and use it to compile Rockbox. Or install Linux onto a pendrive if the PC supports USB boot, and compile from there (be careful, it will break your pendrive's memory blocks very quickly if you use it to compile lots of times). Or let that Win2000+VirtualBox+Ubuntu+GCC compiling Rockbox thing if you're satisfied with it. You choose ;)
keyb_gr:
Using a USB stick would seem like a good idea... well, if I weren't stuck with USB 1.1 and no front ports. I have no idea whether ye olde P3B-F (anyone remember that one?) will boot from USB either, though I presume it does.
Anyway, recompiles are quite speedy now, especially if all that needs to be redone is the bin file.
Navigation
[0] Message Index
[#] Next page
Go to full version