Click in the nick column to highlight everything a person has said.
The icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2010-04-25

00:01:26

Quit DerPapst(Quit: Leaving.)

00:01:48

Join bluebrother[0] (~dom@rockbox/developer/bluebrother)

00:03:43

Join archivator[0] (~archivato@stu0279.keble.ox.ac.uk)

00:04:49

Quit anewuser(Quit: http://xrl.us/NitroQueer What do you know...THE WORLD'S first NTRQ (that's for NES/FAMICOM) tracking compo. Have powerpak? Try it out! Otherwise ROM IMAGE.)

00:08:30

Quit xavieran(Ping timeout: 258 seconds)

00:21:35

Quit merbanan(Ping timeout: 240 seconds)

00:28:08

Quit pamaury(Quit: Page closed)

00:32:50

Quit archivator(Quit: Leaving)

00:33:07

Quit ved(Quit: Changing server)

00:44:52

Join __arbingordon[0] (~w@c-68-44-148-113.hsd1.pa.comcast.net)

00:45:39

Join ved[0] (ved@ddsbox.co.cc)

00:46:04

Nick __arbingordonis now known as arbingordon (~w@c-68-44-148-113.hsd1.pa.comcast.net)

Quit ender`(Quit: I don't see what C++ has to do with keeping people from shooting themselves in the foot. C++ will happily load the gun, offer you a drink to steady your nerves, and help you aim.-- Peter da Silva)

as of now, I'm *pretty* happy with how rb handles albumart which is perfectly reasonable for embedded devices as long as suitable tools exist, so I'm not really happy with accepting a hacked together solution

saratoga: my idea for handling tag images was something along the lines of passing the loader an alternate getc implementation - this could read in the data and do whatever transformation needs to be done, seeking past non-image data, desync, base64 decode (for some tag types)

i'm also *pretty* sure that getc is inlined right now. and that a read hook would not need to be so much worse. it would take a uintptr_t opaque argument in place of the file handle, and otherwise look like a "real" read.

but the hook version would need to fill the buffer, and then transform it as needed. to my knowledge the transforms done on image data in tags are all expanding, so you should always be able to fit the decoded image data into the same space

kugel: i also think this might be easier to implement. hooking at getc means that the hook also has to implement stuff that's in getc now - checking available buffer and advancing the pointer if not empty. also hooking read means that we don't have to worry at all about how getc changes impact ungetc.

kugel: This may be a language issue - "objective" means based only on observable phenomenon - as long as you're assuming that the time won't be noticeable but haven't measured it yet, it's still subjective.

anyway, if we support PNG loading, we have to also think about how often interlaced PNGs are going to come up, how hard it's going to be to explain to users why their AA won't load and how to fix it, and how much they'll still complain even though they can now load *some* PNGs instead of *none*.

Unhelpful doesn't, and won't, use embedded AA... but doesn't *terribly* mind tossing some pointers re: implementation, and perhaps dropping that patch into a branch in his git and looking at what could improve.

I think embedded jpeg might be added to improve compatibility, since it's apparently bloody common. But I really would see an alternative of making a tool available on a wiki that'll go through a collection with embedded AA and extract it to Rockbox usable AA.

hrm, right now the buffering code figures out whether to call the jpeg or the bmp loader itself, right? what if we wrapped individual filetype loaders in a frontend that *also* understands embedded AA (and does what is needed to get it). if the metadata code is then capable of reporting whether a file contains embedded art and how to load it, this also makes it easy on other things that want to use the current AA (i'm thinking of sliding

depends on the format. vorbis comments were *always* meant to be text-only. id3v2 has specific tags for images, and others for other binary data, but is designed to allow that it might be played by a player that knows mp3 but not id3

probably a KB or two for the code for deciding which loader to call for album art, and for the code to search for both formats. and the scaler could possibly be more tightly bound to the loader if it was only going to be used by one loader... maybe it could even be inlined and the compiler could reduce/specialize it bit.

I've actually met a few people that *thought* RB did embedded AA because they used WMP and didn;t realise that it saves a hidden/system "Filder.jpg" in the albums directory...and they'd just been drag & dropping from the WMP library

wodz: i think the only suggestion is for a separate "Hardware EQ" screen that lets users adjust a hw eq as flexibly as possible while keeping the regular sw eq screen, and having settings for any other dsp present in the dac

as a note to the png discussion - the png viewer is still colour screens only. And even if there was a greyscale "port" it could use the greyscale library in a plugin, not in the core (bmp in the core vs. the plugin does the same btw.). And I also can't see the benefit of png for e.g WPS graphics, the file size difference is probably not big for most of them with the exception of the backdrop maybe and bmp decoding is super simple and png is not

yes that's true. My point is that a the SVG file will also be big relatively the bmp ones because the resolution is quite low. And so does it makes sense to keep in SVG rather than generating a bmp from it for each target ? I don't know the answer either :)

kugel: a test compile with gcc4.5 for coldfire went fine, with the only error being the nsf codec not fitting in iram, and a handful of new warnings, haven't been able to try the buid yet thoug so can't say anyting about performance or if it even works :)

iTunes and e-music both ship files with embedded album art. For people who don't do as I do and only deal with complete albums embedded appears to not only be common, but to make some sense. Regardless, embedded is /common/,

Afternoon - my HDD on my iRiver H340 died. I'm going to do the CF-Mod but my main use will be recording concerts (that permit taping). Should I be overly concerned about the CF card write speeds? Or will they all generally be fast enough for audio recording? Thanks

http://www.rockbox.org/wiki/IfpCryptanalysis However I ran into problems when i tried running irde on E10's firmware. It seems on the positions in the blocks where there should be checksums (offset x*51 + 50, and offset 255), large parts of the E10 firmware has no checksums but something else entirely. Even if the contents of the blocks varies, the "checksums" stays the same, so they're not checksums.

kugel: but something different. I tested the simplify PLA patch on my Ondio and it works fairly well on my Ondio, with the one of metronome. It's still better than SVN but I *believe* an earlier patch worked better. Unfortunately it's long ago that I tested earlier version and I only remember being impressed before, I'm not a 100% sure though if it also was the Ondio etc.

mozetti: Just a question - why wav instead of lossless wavpack? If you're worried about write speeds for some reason (as linuxstb mentioned, it shouldn't be a big concern) that would give you even more elbow room.

I've added a repeat detection to the system trace logging function. I'm wondering if that's a good idea at all, as it will consume all repeated lines and only output a duplicate count when the next different line gets logged

That said, we could simulate tone controls for targets with hardware tone controls, *but* if we do that this should either use the host's hardware (if possible), or if it has to be done in software, it should be done in the simulator layer, not in the app layer

bluebrother: if you find time, can you test the paralell tts patch from archivator on Mac with TTSCarbon ? (i had problems with sapi, so we should make sure it runs fine with the other non-paralel tts before commiting)