00:00:40 | amiconn | LinusN: Perhaps the tag handling in mpeg.c should be rewritten, because of several reasons: |
00:01:06 | LinusN | amiconn: yes |
00:01:09 | amiconn | (1) It has a static limit of 16 tracks |
00:01:31 | amiconn | (2) If this limit is exceeded, it seems to cause problems |
00:01:56 | LinusN | 1) we want static limits |
00:02:03 | LinusN | 2) that's the bug |
00:02:25 | amiconn | (3) It uses both an array of structs and a pointer array to these. Why it's designed that way is beyond me |
00:03:02 | amiconn | (4) There are frequent NULL pointer accesses while playback |
00:03:20 | LinusN | 3) that's an old relic from the days the structs were allocated from the pool of 16 structs |
00:03:34 | LinusN | 4) yes, that's another bug |
00:03:47 | amiconn | (5) the struct array for 16 tags consumes a whopping 24 K of ram (bss) |
00:04:20 | LinusN | "whopping" :-) |
00:04:48 | amiconn | For what it does, I consider this "whopping" |
00:05:09 | amiconn | I wonder why it is necessary to convert & buffer the tags of all loaded tracks at load time. |
00:05:39 | LinusN | because we don't want to spin up again just to read the tags? |
00:06:22 | amiconn | Aren't the tags loaded interspersed with the mp3 data, so that they are in ram already, between the tracks? |
00:06:48 | LinusN | they aren't loaded into the mp3 buffer |
00:07:01 | LinusN | only mp3 data is in the buffer |
00:07:20 | LinusN | and we need a copy of the tags, since the tag data will be gone when the buffer fills up the next time |
00:07:36 | LinusN | (if they were loaded into the mp3 buffer, that is) |
00:07:51 | amiconn | I'd rather suggest to only store the track start index at load time (this table could have many more entries, since these are simple pointers) |
00:08:33 | amiconn | The tags could then be decoded when needed (e.g. when the previous track starts) |
00:08:42 | LinusN | "track start index"? |
00:09:20 | amiconn | Yes, the buffer index where the track starts |
00:09:37 | LinusN | you mean load the tags into the mp3 buffer? |
00:10:07 | amiconn | Yes, although this is slightly more work for v1 |
00:10:27 | LinusN | yes it is, and the swapping will be trickier |
00:11:09 | LinusN | since you mustn't swap the tag data |
00:11:20 | amiconn | Of course |
00:12:10 | amiconn | My first though was to place the already decoded tags into the buffer, but this won't work when the buffer wraps in the middle of the struct |
00:12:24 | LinusN | we have discussed this approach several times, and found it pretty complicated |
00:14:08 | amiconn | If we stay with the current approach (an array of structs) I still don't get why there are 16 pointers, allocating from a pool of 16 structs. This is complicated too, for no reason. We could use the struct array directly as a ring buffer |
00:14:26 | | Quit edx () |
00:15:23 | amiconn | On the contrary, if we would buffer the tags within the mp3 buffer, the ram allocation for tags would be dynamic. |
00:15:48 | LinusN | amiconn: did you read my answer for your question 3)? |
00:17:04 | amiconn | Yes, I read that, but I still don't get why this was done. Did the usused struct got used for something else? |
00:17:54 | LinusN | i don't remember why it was designed like that back then |
00:18:21 | LinusN | i think it might come from the days when we had a malloc |
00:18:22 | amiconn | For the typical use as a music player, there are mostly 1..2 tracks in memory, so having 16 slots is wasting ram. On the other hand, if you have short clips, 16 slots might even be too few :( |
00:19:46 | LinusN | yes, i agree that we need a better way of handling this |
00:20:20 | LinusN | but i think loading the tags into the mp3 buffer will lead to complicated code |
00:20:21 | lImbus | where's the problem to make this variable ? |
00:20:37 | LinusN | we don't have dynamic memory |
00:20:54 | lImbus | uhh. that's some argument. |
00:21:31 | lImbus | how are the limits for "max files in dir browser" and playlist handled ? |
00:21:52 | amiconn | These pointers are btw the reason for the NULL pointer accesses. |
00:23:24 | LinusN | lImbus: they are taken from the mp3 buffer at boot time |
00:23:30 | LinusN | amiconn: ah |
00:25:50 | amiconn | LinusN: You said that buffering the tags within the mp3 buffer complicates the bitswapping. This is only true if the tracks are swapped at load time. We could swap before playback instead (the next dma chunk) |
00:26:33 | amiconn | This could in fact help portability - chances are that another architecture doesn't need bitswapping |
00:27:38 | amiconn | I consider bitswapping to be a part of the "mp3 driver", while handling the tags, track changes, reloads etc. is part of the playback engine |
00:27:49 | LinusN | finding the next dma chunk will still be more complicated |
00:28:18 | LinusN | today, everything in the mp3 buffer is mp3 data, so we can just grab the next 64k |
00:28:33 | amiconn | We don't... |
00:28:43 | lImbus | ok, that's what I meant. isn't the case of having 16 tracks beeing smaller than 2 MB (or even 8MB) small enough to make that configurable like max dirbrowser ? |
00:29:03 | lImbus | Frihet must have chunks smaller than 128 kB |
00:29:22 | Frihet | I can look |
00:31:32 | Frihet | The MP3 files average about 60KB |
00:32:37 | Frihet | They are short phrases like "Hvordan har du de" |
00:33:21 | LinusN | amiconn: yes, there is the special cases when the end of the buffer is reached, and at track boundaries |
00:33:55 | LinusN | but the tags-in-buffer approach complicates it even more |
00:34:13 | amiconn | LinusN: Yes, exactly. We already check for track boundaries, so having the tag data at the beginning of the next tracks shouldn't add much complexity |
00:34:18 | LinusN | i'm not saying that it is hard, i just mean that the code will get harder to understand |
00:35:03 | LinusN | and when the tags are big, we will waste buffer space, like when some silly person sticks album covers in the tag |
00:35:35 | amiconn | If we pre-decode the tags and put the struct at the beginning of the track, the size will be constant. |
00:36:04 | amiconn | This has to be copied when starting playback of that track, since otherwise it is gone at the next reload |
00:36:37 | amiconn | The only special case would be when the buffer would wrap within the tag data, but that can be avoided by wrapping prematurely |
00:36:39 | LinusN | yup |
00:39:00 | amiconn | Btw: my interpretation of the posix rules for O_TRUNC is correct :) |
00:39:07 | LinusN | good |
00:40:03 | amiconn | So I'll try what you suggested, and hope it doesn't ruin my box' file system (of course I have a backup) |
00:41:24 | * | amiconn digs for the correct irc backlog |
00:43:16 | Frihet | I will leave bug 949268 with the experts and check in later in the week. If it's too big a deal, just let me know. |
00:43:48 | *** | Saving seen data "./dancer.seen" |
00:44:07 | | Quit Frihet ("ChatZilla 0.9.52B [Mozilla rv:1.6/20040114]") |
00:44:43 | amiconn | LinusN: As you probably found, I implemented the new screen_dump() without using assembler ;) |
00:46:27 | | Join SmoothOperator [0] (~c35d2208@labb.contactor.se) |
00:46:36 | | Quit SmoothOperator (Client Quit) |
00:56:12 | LinusN | amiconn: saw that, and was pleased :-) |
00:56:17 | LinusN | sleep time |
00:56:18 | LinusN | nite all |
00:56:24 | | Part LinusN |
01:00 |
01:10:38 | | Join Frihet [0] (~chatzilla@38.119.217.96) |
01:13:07 | | Quit Frihet (Client Quit) |
01:26:34 | | Join SmoothOperator [0] (~acbeb032@labb.contactor.se) |
01:42:05 | | Quit SmoothOperator ("CGI:IRC (Ping timeout)") |
02:00 |
02:23:05 | | Part amiconn |
02:43:50 | *** | Saving seen data "./dancer.seen" |
02:49:22 | | Join NegativeK [0] (~negk@68.114.40.130) |
03:00 |
03:01:30 | | Quit elinenbe (" HydraIRC -> http://www.hydrairc.com <- irc client ownage!") |
04:00 |
04:01:30 | | Quit lImbus (Remote closed the connection) |
04:23:29 | | Quit NegativeK ("Leaving") |
04:23:30 | | Join NegativeK [0] (~negk@68.114.40.130) |
04:43:54 | *** | Saving seen data "./dancer.seen" |
05:00 |
05:21:29 | | Join grogro [0] (~gromit@ALagny-151-1-23-64.w83-114.abo.wanadoo.fr) |
05:39:50 | | Quit maikeul (Read error: 110 (Connection timed out)) |
06:00 |
06:27:50 | | Join midk [0] (~midk@c-24-18-39-204.client.comcast.net) |
06:35:46 | | Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
06:35:51 | | Part scott666_ |
06:43:55 | *** | Saving seen data "./dancer.seen" |
07:00 |
07:32:33 | | Join LinusN [0] (~linus@labb.contactor.se) |
08:00 |
08:09:05 | | Nick midk is now known as midk|sleep (~midk@c-24-18-39-204.client.comcast.net) |
08:20:21 | | Join hardeep [0] (1098@208.247.65.237) |
08:20:48 | hardeep | hey, does anyone know where I can download some sample rvf files? |
08:23:28 | hardeep | aha, found some: http://rockbox.haxx.se/newvid/ |
08:25:15 | | Join Zagor [242] (~bjst@labb.contactor.se) |
08:26:28 | LinusN | Zagor: today is payday for you, you owe me a lunch :-) |
08:26:39 | Zagor | sure |
08:27:36 | dwihno | :-) |
08:36:28 | | Part LinusN |
08:36:38 | | Join LinusN [0] (~linus@labb.contactor.se) |
08:37:41 | dwihno | ConTraktor |
08:43:56 | *** | Saving seen data "./dancer.seen" |
08:45:55 | Zagor | whoa, what happened to todays daily build? |
08:47:24 | dwihno | ?! |
08:47:48 | Zagor | hmm, bug and patch lists are empty too. network blackout? |
08:47:50 | dwihno | Perhaps somebody tried integrating the rombox build (Badger?) |
08:48:23 | | Join [IDC]Dragon [0] (~d9ff8454@labb.contactor.se) |
08:48:40 | [IDC]Dragon | 'morning from me logpeeker |
08:48:46 | Zagor | :) |
08:49:09 | [IDC]Dragon | hardeep: here are some really nice videos: http://rockboxvideo.redbreva.co.uk/ |
08:49:45 | [IDC]Dragon | and a few links to mediocre ones: http://rockbox.haxx.se/mail/archive/rockbox-archive-2004-02/0189.shtml |
08:52:08 | [IDC]Dragon | hardeep: got enough bandwidth? |
08:53:32 | [IDC]Dragon | did anybody check if the daily ROMbox build works? |
08:56:05 | | Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) |
08:56:42 | Bagder | Zagor: you checked why the daily builds failed? |
08:56:46 | dwihno | When you talk of the trolls ;) |
08:56:58 | Zagor | looking at it now. the bug and patch lists are empty too. |
08:57:10 | Zagor | Bagder: you check the builds, i'll check the lists ok? |
08:59:27 | Bagder | something truly weird happened |
08:59:44 | Bagder | the size of the tarball package is a lot smaller today |
09:00 |
09:00:03 | [IDC]Dragon | (my question somehow got answered) |
09:01:37 | Bagder | I can't see how the problems can be related |
09:01:51 | Bagder | Zagor: didn't you get some clues in a crontab mail? |
09:02:02 | Bagder | or is it dev/nulled? |
09:02:44 | Zagor | i think i deleted it :( |
09:03:40 | [IDC]Dragon | bbl |
09:03:58 | [IDC]Dragon | (learned that acronym yesterday) |
09:04:01 | | Part [IDC]Dragon |
09:06:36 | Bagder | hm |
09:07:45 | LinusN | Bagder: bleeding edge and daily builds are done by differents scripts, right? |
09:08:16 | | Quit Bagder ("Leaving") |
09:17:51 | LinusN | Zagor: u there? |
09:24:47 | Zagor | rerunning daily builds... |
09:26:20 | webmind | morning |
09:26:31 | Zagor | hi |
09:29:07 | | Join amiconn [0] (~jens@pD9E7DE1A.dip.t-dialin.net) |
09:29:25 | amiconn | morning |
09:32:14 | LinusN | hi |
09:32:37 | LinusN | amiconn: regarding the tag discussion |
09:33:30 | LinusN | we need to keep the current and the upcoming tag in memory, otherwise the next-track wps info won't work |
09:33:37 | amiconn | Of course |
09:34:08 | Zagor | daily builds now work. the problem was "configure update" mangled the Makefile for some of the targets. |
09:35:03 | | Join amiconn_ [0] (~jens@pD9E7F378.dip.t-dialin.net) |
09:35:43 | | Join amiconn__ [0] (~d9092244@labb.contactor.se) |
09:36:41 | | Quit amiconn (Nick collision from services.) |
09:36:41 | | Nick amiconn_ is now known as amiconn (~jens@pD9E7F378.dip.t-dialin.net) |
09:37:11 | | Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) |
09:38:52 | amiconn__ | Zagor: The tarball is now much larger than the last few days... |
09:39:04 | Bagder | looks wrong |
09:40:42 | Bagder | and so it is |
09:40:56 | Bagder | it contains a rockbox-daily-20040907 dir |
09:41:00 | Bagder | with contents |
09:41:24 | Bagder | like rockbox-daily-20040907/rockbox-daily-20040907/apps/ |
09:41:41 | LinusN | i guess someone has unpacked it in the build dir when we examined the build errors |
09:42:03 | Bagder | yes "somone" must have ;-) |
09:42:10 | * | Bagder can't type |
09:42:27 | LinusN | but he can unpack a tar file :-) |
09:42:38 | Bagder | *I* didn't do that |
09:42:46 | LinusN | sorry :-) |
09:42:53 | Bagder | since I can't type, I can't unpack either ;-) |
09:42:59 | amiconn__ | LinusN: To flash that into the box? |
09:43:03 | * | LinusN points to Zagor |
09:43:16 | * | Bagder joins LinusN in the pointing |
09:43:23 | amiconn__ | Ooops, I read "uclpack" instead of "unpack" |
09:43:53 | Mode | "#rockbox +o LinusN " by ChanServ (ChanServ@services.) |
09:44:05 | LinusN | amiconn__: want to kick amiconn? |
09:44:14 | amiconn__ | LinusN: No. |
09:44:18 | LinusN | ok |
09:44:32 | amiconn__ | This is my home box, I just have to wait 15 min to re-connect to it |
09:44:37 | Zagor | well i didn't unpack anything anywhere |
09:45:11 | LinusN | weird |
09:45:31 | Bagder | it might be because it was re-run on the same date |
09:45:34 | Bagder | somehow |
09:45:41 | Bagder | let's ignore it and hope it works better tomorrow |
09:45:44 | | Join kurzhaarrocker [0] (~knoppix@p50877DD2.dip0.t-ipconnect.de) |
09:45:45 | LinusN | or we ran the update.sh script in the wrong dir |
09:46:13 | Bagder | Zagor: did you update the uclpack tool? |
09:46:44 | Zagor | nope, didn't find the source then got busy with other stuff |
09:47:00 | Bagder | the source is in the RomBox wiki page |
09:47:14 | Zagor | no, that's just one file. more is needed. |
09:47:26 | Bagder | aha |
09:47:32 | Bagder | yes, ucl-1.01 |
09:47:43 | Bagder | I'll fix it |
09:47:46 | Zagor | thanks |
09:48:49 | Bagder | it uses the /usr/local/bin one, right? |
09:50:25 | Bagder | it is updated now anyway |
09:50:26 | Zagor | i think so yes |
09:51:02 | Bagder | gcc 3.0.4 makes a 5K larger ucl file than 3.3.1 |
09:51:32 | Bagder | we should upgrade the cross-compiler stuff on labb as well |
09:51:54 | Zagor | yeah |
09:53:02 | Bagder | "Output is 216 bytes larger than max (188400)" |
09:53:11 | Bagder | 3.0.4 can't make a rombox for the v2 |
09:53:21 | Zagor | boo |
09:55:25 | Bagder | annoying |
09:55:32 | | Quit amiconn__ ("CGI:IRC 0.5.4 (2004/01/29)") |
09:58:46 | amiconn | Back for real :) |
10:00 |
10:03:01 | | Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) |
10:03:12 | [IDC]Dragon | back again |
10:03:28 | amiconn | hi Jörg |
10:03:49 | [IDC]Dragon | no Ondio luck yesterday? (saw your bid) |
10:04:04 | amiconn | Was too expensive imho |
10:04:16 | amiconn | Today another Ondio is due (in the evening) |
10:04:18 | [IDC]Dragon | cheapskin! |
10:07:48 | [IDC]Dragon | amiconn: on a different one: nice screendump function |
10:08:29 | [IDC]Dragon | or, bad one before, 1.8K buried, ts, ts |
10:09:00 | [IDC]Dragon | do we have more like that? |
10:09:28 | LinusN | very likely |
10:09:39 | [IDC]Dragon | where? |
10:10:10 | LinusN | there is a possibility that we have more debug functions that have ended up in the official build |
10:10:39 | LinusN | and those are probably not very optimized |
10:11:10 | [IDC]Dragon | scary... |
10:11:30 | LinusN | not at all, that's how things work |
10:11:54 | LinusN | there is a first version of everything, then you improve it |
10:12:05 | amiconn | LinusN: I'd suggest eliminating most of the debug menu for the upcoming 2.3 release, leaving only stuff that could really help to spot problems |
10:12:17 | LinusN | amiconn: absolutely |
10:12:22 | [IDC]Dragon | I was joking, don't take it too serious |
10:12:33 | LinusN | [IDC]Dragon: no offense taken |
10:13:03 | LinusN | we can at least put the debug functions on a diet |
10:13:17 | * | [IDC]Dragon has a deja-vu: "upcoming 2.3 release" |
10:13:43 | LinusN | we need to find the nasty recording bug that Paul experiences |
10:13:55 | amiconn | Candidates would be the mas register & codec debug... |
10:13:56 | [IDC]Dragon | 3KB to go for "native FM" rombox |
10:13:59 | LinusN | with lots of corrupt frames |
10:14:39 | [IDC]Dragon | LinusN: can we reproduce that? |
10:14:56 | LinusN | amiconn: do you get corrupt frames? |
10:15:16 | * | [IDC]Dragon shoul try recording |
10:17:08 | amiconn | LinusN: Usually I almost use recording. I plan to do even more extensive recording tests, though |
10:17:29 | amiconn | I would need a reliable tool to spot corrupt frames for that |
10:18:03 | [IDC]Dragon | amiconn: have you looked at my frame parser in rvf_mux? |
10:18:17 | amiconn | mp3utility is a bit questionable, and mp3fixer is definitely buggy, at least the windows binary |
10:18:28 | amiconn | [IDC]Dragon: No, not yet |
10:18:38 | [IDC]Dragon | should be easy to make a tool from it |
10:19:15 | [IDC]Dragon | it walks the headers, inspects them all |
10:19:31 | [IDC]Dragon | and recognises lost/regained sync |
10:19:38 | amiconn | Does it check the frame checksum (if there is one)? |
10:19:50 | [IDC]Dragon | no |
10:20:08 | [IDC]Dragon | feel free to add that ;-) |
10:20:54 | LinusN | the code in mp3data.c and the vbrfix code should be a good base to build upon |
10:21:14 | [IDC]Dragon | so we got choices |
10:28:28 | amiconn | [IDC]Dragon: As you asked whether we have more functions that use a lot of ram: look at the ro(ck|m)box.map, especially the bss space each module takes |
10:30:13 | [IDC]Dragon | "ro(ck|m)box", hehe |
10:30:58 | [IDC]Dragon | yes, that's a start. but I don't know how much is "justified", and no names for static stuff |
10:32:58 | amiconn | One of those little ram suckers is mpeg.o, because of the tag handling... |
10:33:22 | [IDC]Dragon | putting salt on LinusN's wounds? |
10:33:42 | [IDC]Dragon | (if that german saying translates correct) |
10:43:14 | * | [IDC]Dragon still thinks malloc would be nice |
10:44:00 | *** | Saving seen data "./dancer.seen" |
10:44:00 | Bagder | malloc for what? |
10:44:27 | Zagor | malloc is a waste of ram |
10:44:28 | [IDC]Dragon | for not having worst-case static allocation all the time |
10:44:52 | Zagor | the only result will be lovely out-of-memory handling code all over the place |
10:44:58 | [IDC]Dragon | it's a tradeof, not a waste |
10:45:44 | [IDC]Dragon | out of memory is an assert within malloc |
10:45:45 | Zagor | ok i won't dismiss it right off like that. where do you suggest we'd benefit from it? |
10:46:14 | [IDC]Dragon | the tag handling, for example |
10:46:16 | amiconn | I'm tempted to rewrite the tag handling (dynamically within the mp3 buffer, as I discussed with LinusN). I wouldn't need malloc for that |
10:46:30 | Zagor | but with an assert we'd crash whenever we run out of memory!? |
10:47:23 | [IDC]Dragon | we have the mp3 buffer to munch from, we won't run out of mem for the other stuff |
10:47:53 | Zagor | it's pretty icky munching from the mp3 buffer while music is playing |
10:48:19 | * | [IDC]Dragon thinks vaguely about a way to have the unallocated as a linked buffer list |
10:48:35 | Bagder | it is possible |
10:48:44 | Bagder | but icky |
10:48:49 | [IDC]Dragon | whenever mem is needed, it should be taken from the played end |
10:49:00 | Bagder | but... |
10:49:03 | [IDC]Dragon | if not possible, from the newes unplayed |
10:49:20 | Bagder | so it would need to reread data? |
10:49:28 | [IDC]Dragon | yes, something like that |
10:50:14 | amiconn | An ugly thing with malloc is memory fragmentation (without having an mmu of course). How would you handle that? |
10:50:34 | dwihno | MMU? |
10:50:49 | Bagder | it fragments even with MMU |
10:50:59 | [IDC]Dragon | as we wade through, it will defragment again |
10:51:13 | amiconn | Bagder: Yes, but you can remap the unused pieces into one region |
10:51:45 | LinusN | we have had this discussion countless times |
10:51:55 | [IDC]Dragon | there's different algorithms for reducing fragmentation |
10:52:01 | [IDC]Dragon | LinusN: sorry |
10:52:23 | LinusN | don't worry, this time we might come to a different conclusion |
10:52:31 | Bagder | reducing is the word, it can't be avoided |
10:52:36 | [IDC]Dragon | sounds optimistic |
10:53:15 | Bagder | I still haven't read a good argument why it is good in current rockbox |
10:53:28 | LinusN | Bagder: agreed |
10:53:32 | [IDC]Dragon | well, by profession I'm working on an embedded system for mobile phones |
10:53:53 | [IDC]Dragon | and we malloc like crazy |
10:54:01 | [IDC]Dragon | no problems yet |
10:54:14 | Bagder | I'm sorry, but that doesn't really answer my question |
10:54:28 | Bagder | I too usually use malloc a lot |
10:54:53 | [IDC]Dragon | we're probably not even aware any more in how many places we put memory aside |
10:55:45 | [IDC]Dragon | like, to communicate the recording pathname to the mpeg task, there are 2 static buffers |
10:56:33 | [IDC]Dragon | really needed only until the taskswitch |
10:57:18 | Bagder | I believe the cost of adding code for handling segmented mpeg playback, malloc and everything is much greater than the amount of memory currently "wasted" due to our lack of malloc - but this is only my suspicion |
10:57:35 | [IDC]Dragon | a valid one |
10:59:13 | Bagder | btw |
10:59:18 | [IDC]Dragon | certainly I also don't know, it's just by gut feeling I woudn't build an embedded system of this size without malloc |
10:59:24 | Bagder | I think we should release 2.3 soon |
10:59:30 | [IDC]Dragon | ;-) |
11:00 |
11:01:38 | LinusN | also consider the amount of debugging time we have gained by not having to hunt memory leaks |
11:02:08 | Zagor | or oom crashes |
11:02:17 | LinusN | or defragmentation problems |
11:02:51 | LinusN | dynamic memory is a two-edged sword imho |
11:02:57 | | Join lImbus [0] (~manuel@kernel.cycos.net) |
11:03:05 | LinusN | i avoid it if i can |
11:03:12 | * | [IDC]Dragon shuts up on the subject |
11:03:16 | LinusN | :-) |
11:04:41 | [IDC]Dragon | how about a call for 2.3 feature freeze? |
11:04:54 | [IDC]Dragon | or are we not freezing any more? |
11:04:58 | Bagder | good idea |
11:05:10 | [IDC]Dragon | we appear frozen already |
11:06:16 | [IDC]Dragon | I'll probably folk (temporarily) for Ondio, but that's a different story |
11:06:31 | Bagder | we should fix the gcc on the build box before release so that we can offer rombox on as many configs as possible |
11:07:08 | [IDC]Dragon | s/folk/fork |
11:09:39 | [IDC]Dragon | do we need some more field testing with gcc3.3.1? |
11:10:32 | Bagder | we need to upgrade the rockbox.haxx.se's gcc installation to 3.3.1 from 3.0.4 to make smaller files |
11:10:42 | [IDC]Dragon | yes |
11:11:20 | [IDC]Dragon | and perhaps the build results could use some more testing, because of the compiler change? |
11:11:27 | Bagder | true |
11:11:41 | Bagder | just in case |
11:14:32 | [IDC]Dragon | btw, gcc3.3.1 now works on my box, too |
11:14:45 | [IDC]Dragon | thanks to BC's devkit |
11:15:07 | Bagder | bbl |
11:15:09 | | Quit Bagder ("Leaving") |
11:31:11 | | Quit NegativeK (Read error: 113 (No route to host)) |
11:59:08 | | Join dwihno_ [0] (~dw@81.8.224.89) |
12:00 |
12:07:40 | | Quit dwihno (Read error: 60 (Operation timed out)) |
12:10:27 | | Join dwihno [0] (~dw@81.8.224.89) |
12:17:21 | | Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) |
12:24:39 | | Quit dwihno_ (Read error: 110 (Connection timed out)) |
12:32:05 | lImbus | Bagder: can you tell me more about the rockbox-funds ? |
12:32:31 | Bagder | it is the donated money via the "donate" paypal button on the site |
12:34:07 | lImbus | mhmm. would like to donate a small bit too, but mind to open a paypal stuff for only that. |
12:34:30 | Bagder | I don't think you need to do that |
12:34:42 | Bagder | you can pay with a credit card if you wish |
12:36:04 | lImbus | mhmm. don't have one. that's the main issue I think. |
12:36:32 | lImbus | doesn't it have a SWIFT and BIC like european international transfers now ? |
12:36:46 | Bagder | I don't know, it might |
12:41:28 | | Quit dwihno (Read error: 110 (Connection timed out)) |
12:44:01 | *** | Saving seen data "./dancer.seen" |
12:44:31 | lImbus | can't find anything concerning that. |
12:47:27 | Bagder | me neither |
12:53:17 | Lynx_ | |Imbus: are you german? |
12:56:04 | Lynx_ | https://www.paypal.com/de/ |
12:59:18 | lImbus | not really. but that seems to be solution, as soon as I am willing to create another account for that. I simply don't want to have a special account on nearly every internet page |
13:00 |
13:17:21 | | Quit Bagder ("Leaving") |
13:42:10 | | Join dwihno [0] (~dw@81.8.224.89) |
13:45:18 | | Join yousan [0] (~yousan@peta5.u-aizu.ac.jp) |
13:45:47 | | Quit yousan (Client Quit) |
13:53:41 | Zagor | whee, the iriver uses the isd-300 usb/ata bridge |
13:54:01 | Zagor | it's only renamed "cypress cy7c68310" since cypress bought isd |
13:54:44 | kurzhaarrocker | How much is in the rockbox fund? Can we buy one too? :) |
13:54:57 | Zagor | we will |
13:55:17 | * | kurzhaarrocker was thinking about buying cypress |
13:55:25 | Zagor | haha ok |
13:57:08 | | Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) |
13:58:32 | dwihno | Cypress hill! \o/ |
13:59:23 | kurzhaarrocker | One Cypress should do. Or do we need a whole forest? |
14:00 |
14:01:31 | LinusN | we just need some seeds |
14:01:50 | LinusN | and then we just wait a few generations :-) |
14:02:28 | [IDC]Dragon | if only buying a box would be enough... |
14:02:46 | Zagor | [IDC]Dragon: have you got the ondio yet? |
14:02:59 | [IDC]Dragon | Zagor bought an AV3x0 long time ago, still no Rockbox on it |
14:03:14 | [IDC]Dragon | Zagor: not yet :-( |
14:03:29 | [IDC]Dragon | looks like it won't reach here today |
14:04:33 | LinusN | it took 2 days for my fm recorder to go from USA to Sweden, but it took almost a week to get it through customs... |
14:05:00 | [IDC]Dragon | no customs this time, it's from germany |
14:05:18 | kurzhaarrocker | You should ship those things without good music on int, LinusN |
14:05:27 | kurzhaarrocker | -t |
14:05:57 | LinusN | it was new, with only those default french crap songs on it |
14:06:15 | [IDC]Dragon | repairing mp3 players must be a good source of music |
14:06:21 | LinusN | indeed |
14:06:30 | [IDC]Dragon | maybe I should open up my shop |
14:06:42 | LinusN | the "send me your songs for analysis" scheme works good for me :-) |
14:06:55 | [IDC]Dragon | :-/ |
14:07:42 | kurzhaarrocker | With french songs its different. Quarantine. They must be relabledt to "Freedom Songs". |
14:11:16 | Zagor | [IDC]Dragon: i admit i bought the av a bit early :) |
14:13:04 | Zagor | [IDC]Dragon: if you like, the rockbox fund can sponsor the ondio |
14:14:18 | [IDC]Dragon | whoa, what a nice fund |
14:14:43 | [IDC]Dragon | to be fair, let's wait awhile if this proves fruitful |
14:14:55 | Zagor | ok |
14:15:14 | [IDC]Dragon | (before my wishes soar too high) |
14:16:08 | [IDC]Dragon | in case of success, we can direct new Ondio Rockbox user to the donate button |
14:16:21 | [IDC]Dragon | s/user/users |
14:16:31 | Zagor | there's more than one? ;) |
14:16:41 | [IDC]Dragon | not yet ;-) |
14:16:59 | [IDC]Dragon | read: "Ondio Rockbox users" |
14:21:24 | kurzhaarrocker | I hope you are talking about the ondio recorder? |
14:22:14 | [IDC]Dragon | I ordered a recorder, yes |
14:22:45 | kurzhaarrocker | good. |
14:23:56 | [IDC]Dragon | that can be a nice thing about a flash recorder: no moving parts, no noise in the internal mic |
14:24:41 | [IDC]Dragon | 1 GB MMC cards are less than 100 Euro nowadays, I was surprised |
14:25:16 | [IDC]Dragon | (don't tell me I can get a 40 GB disk for that) |
14:25:30 | kurzhaarrocker | well Archos proved that it is possible to have unbearable noise even without moving parts. I hope they improved. |
14:25:55 | [IDC]Dragon | is it so bad? |
14:26:30 | kurzhaarrocker | Rockbox improved it a lot. |
14:26:42 | kurzhaarrocker | It was because of the crappy lcd programming. |
14:26:48 | [IDC]Dragon | when? with what hardware? |
14:26:57 | kurzhaarrocker | The normal Recorder 6 |
14:27:32 | kurzhaarrocker | With the original archos hardware you'd hear and record every lcd refresh. With rockbox it was ok. |
14:27:47 | kurzhaarrocker | (still not the best recording device I ever had...) |
14:28:00 | [IDC]Dragon | always, or gradually improving? |
14:28:21 | kurzhaarrocker | I don't remember any of that trouble with rockbox anywhen. |
14:28:33 | dwihno | crappy lcd programming? |
14:28:42 | [IDC]Dragon | I'm asking because our LCD access is a lot faster since video |
14:28:54 | kurzhaarrocker | dwihno not in rockbox of course :) |
14:29:03 | [IDC]Dragon | about factor of 4 |
14:29:51 | | Join wildstoo [0] (~d512f815@labb.contactor.se) |
14:29:53 | dwihno | kurzhaarrocker: nah, rockbox lcd code is da shiznat! :) |
14:29:55 | kurzhaarrocker | I must admit that I probably haven't used recording with Rockbox after January 2004 because I use a special build with trigger included. |
14:30:15 | LinusN | [IDC]Dragon: that was one of the first things we noticed when we developed rockbox, that the noise was gone |
14:30:53 | [IDC]Dragon | nice. Have you ever held a scope to the LCD clock with Archos s/w? |
14:31:00 | LinusN | nope |
14:31:02 | wildstoo | hi. i recently acquired an Archos Studio 20 with an 80GB HD upgrade.. problem is, WinXP will not format drives that are greater than 32GB as FAT32. |
14:31:12 | LinusN | wildstoo: tough luck :-) |
14:31:29 | [IDC]Dragon | use Paragon or other tools to format |
14:31:34 | Bagder | windows is a fine OS *really* |
14:31:37 | LinusN | i think some of the partitioning tools out there can help you with that |
14:31:39 | Bagder | ;-) |
14:31:40 | wildstoo | anyone know of any (free) tools that will allow me to format a partition on a USB drive as FAT32 under WinXP? |
14:31:49 | dwihno | wildstoo: get that software |
14:31:54 | [IDC]Dragon | Paragon did it for me |
14:32:07 | LinusN | i use paragon as well |
14:32:10 | [IDC]Dragon | the free demo version was sufficient |
14:32:33 | wildstoo | ok i'll look at Paragon, thanks |
14:33:04 | dwihno | what was it |
14:33:04 | dwihno | paragon partition something |
14:33:04 | dwihno | it is neat |
14:33:04 | DBUG | Enqueued KICK dwihno |
14:33:04 | dwihno | and you can do it with the demo ver |
14:33:55 | wildstoo | $50 :( |
14:34:14 | [IDC]Dragon | http://kb.paragon.ag/paragon/templ/169.jsp?catId=3283 |
14:34:15 | wildstoo | uh.. site says that demo version doesn't let you do any actual operations |
14:34:29 | wildstoo | just play with the UI and see how things MIGHT work if you registered |
14:34:45 | | Quit wildstoo (Client Quit) |
14:34:52 | | Join wildstoo [0] (~d512f815@labb.contactor.se) |
14:35:04 | wildstoo | lol clicked a link and got navigated away |
14:35:10 | wildstoo | should have seen that coming really |
14:35:10 | kurzhaarrocker | Do you have knoppix? |
14:35:27 | wildstoo | (on CGI IRC, firewalled here) |
14:35:38 | Zagor | try ranish partition manager: http://www.ranish.com/part/ it's definitely free |
14:35:45 | wildstoo | nope |
14:35:49 | wildstoo | but i could get it |
14:41:20 | Bagder | syncing 20GB music takes a while |
14:41:42 | kurzhaarrocker | Just imagine you had to do it in real-time, Bagder |
14:41:50 | Bagder | hehe |
14:42:03 | Lynx_ | wildstoo: are you sure windos xp can't do that? |
14:42:16 | Bagder | Lynx_: yes, many people have claimed this |
14:43:11 | LinusN | XP can do it, but it won't let you |
14:43:17 | kurzhaarrocker | Lynx_ only Win95 / Win98 can do it. Upgrading sometimes is not an improvement. |
14:44:02 | LinusN | microsoft want to promote NTFS, so they limit the usage of FAT32 |
14:44:04 | *** | Saving seen data "./dancer.seen" |
14:45:13 | Bagder | rockbox is so lame that hasn't switched to ntfs yet |
14:45:18 | wildstoo | well, FAT32 is a bit crap in many ways |
14:45:26 | | Part Zagor |
14:45:44 | wildstoo | roll on WinFS ;) |
14:46:18 | Bagder | I read they won't include that |
14:46:31 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
14:46:31 | * | kurzhaarrocker wants a portable mp3 player with 5 1/4" floppy. |
14:47:04 | [IDC]Dragon | maybe you find an ATA floppy, just connect it then |
14:47:42 | | Join dwihno_ [0] (~dw@81.8.224.89) |
14:47:47 | | Quit dwihno (Read error: 60 (Operation timed out)) |
14:49:40 | wildstoo | it doesn't matter what drive label you give the drive, does it? |
14:49:53 | wildstoo | doesn't have to be called JUKEBOX or ARCHOS or something, does it? |
14:49:54 | Bagder | nope |
14:49:55 | LinusN | no |
14:50:35 | [IDC]Dragon | just reading the Ondio manual, the firmware doesn't look bad |
14:50:38 | [IDC]Dragon | http://www.minidisc.org/manuals/archos/archos_ondio.pdf |
14:50:51 | [IDC]Dragon | maybe it doesn't need Rockbox? |
14:51:02 | wildstoo | *sigh* 80GB HD over a USB connection = about 24 hours to format it |
14:51:07 | Lynx_ | wait a minute, i just remember if formated my box from xp home two weeks ago... |
14:51:27 | [IDC]Dragon | do a quick format |
14:51:39 | Lynx_ | sure does work for me, xp offers ntfs and fat32 |
14:51:49 | [IDC]Dragon | else this is no-go, tha batteries won't last 24 hours |
14:51:54 | Lynx_ | maybe the drive has to be fat32 to begin with, though |
14:52:05 | wildstoo | i have it connected to mains |
14:52:23 | wildstoo | XP offers FAT32 if the drive is less than 32GB in size |
14:52:25 | [IDC]Dragon | still, this supplies less power than the disk needs |
14:52:29 | wildstoo | mine is 80GB |
14:52:37 | Lynx_ | wildstoo: ah, that's it... |
14:52:38 | [IDC]Dragon | so you will drain the batteries |
14:53:21 | wildstoo | well i copied stuff off it for about 12 hours yesterday and it didn't die |
14:53:24 | wildstoo | and it's still alive now |
14:53:39 | [IDC]Dragon | very surprising... |
14:54:01 | [IDC]Dragon | what model? |
14:54:08 | * | kurzhaarrocker is glad that he has a 2 1/2" -> 3 1/2" adapter... |
14:54:45 | wildstoo | um.. Archos Studio 20 |
14:55:12 | [IDC]Dragon | do the studios have a stonger charger? |
14:55:19 | wildstoo | if you mean the HD itself i have no idea of the model :) |
14:55:22 | [IDC]Dragon | stronger |
14:55:51 | wildstoo | no idea.. it doesn't even show a battery symbol when it's connected to USB anyway |
14:55:54 | wildstoo | so there's no way to tell |
14:58:57 | wildstoo | gets pretty toasty when it's running all night connected to mains |
14:59:07 | wildstoo | :) |
15:00 |
15:11:08 | | Quit Bagder ("Leaving") |
15:11:32 | | Quit wildstoo ("CGI:IRC (EOF)") |
15:13:34 | | Join paultje3181 [0] (~83d3e218@labb.contactor.se) |
15:14:01 | paultje3181 | hi, how can I view JPG's using rockbox? |
15:14:15 | paultje3181 | player version, today's build |
15:14:48 | kurzhaarrocker | The player doesn't have a graphical lcd and can not display jpg's :( |
15:14:55 | paultje3181 | pity |
15:15:04 | paultje3181 | no bmp's as well? |
15:15:17 | kurzhaarrocker | No graphix at all, only text. |
15:15:21 | paultje3181 | damn |
15:15:36 | paultje3181 | I should've bought the recorder :P |
15:15:43 | kurzhaarrocker | :) |
15:16:15 | paultje3181 | I'll try to get text working then |
15:16:33 | paultje3181 | haven't tested it yet, but rockbox sure is great |
15:23:43 | paultje3181 | a smaller font isn't possible as well I guess? |
15:24:20 | kurzhaarrocker | You guessed right |
15:24:43 | [IDC]Dragon | you can move the box further away |
15:24:48 | paultje3181 | :P |
15:25:12 | paultje3181 | I meant to get more text on the display :D |
15:25:52 | paultje3181 | what I pity, now I can get RSI from reading Harry Potter on my jukebox :p |
15:26:30 | kurzhaarrocker | lol! |
15:26:48 | paultje3181 | well, I'm off reading :P |
15:26:57 | paultje3181 | thnx for the info! |
15:27:01 | lImbus | lol @ [IDC]Dragon |
15:27:02 | kurzhaarrocker | no problem |
15:27:38 | | Quit paultje3181 ("CGI:IRC (EOF)") |
15:27:46 | [IDC]Dragon | funny guy |
15:27:46 | | Nick dwihno_ is now known as dwihno (~dw@81.8.224.89) |
15:28:04 | [IDC]Dragon | jpeg on a player, rotfl |
15:28:20 | kurzhaarrocker | Maybe we should have advised him to read the faq instead of harry potter on the player... |
15:28:55 | kurzhaarrocker | Well with those user definable characters there in fact could be a way to visualize jpgs... |
15:29:09 | [IDC]Dragon | certainly, and video |
15:29:48 | [IDC]Dragon | if you redefine them at exacly the time they are displayed |
15:30:34 | kurzhaarrocker | ... and by synchronizes shaking you might even increase the display area... |
15:30:46 | [IDC]Dragon | ah, yes |
15:31:23 | [IDC]Dragon | and by syncing to external RGB light pulsed you'll get color |
15:31:34 | kurzhaarrocker | yay! :D |
15:31:58 | [IDC]Dragon | maybe 3D if you move it back and forth, too |
15:32:27 | kurzhaarrocker | Now let's find a hard drive that survives that treatment. |
15:33:57 | kurzhaarrocker | After watching "lord of the rings" with that method you don't need a fitness center any more. |
15:35:18 | [IDC]Dragon | i'm off |
15:35:23 | | Part [IDC]Dragon |
15:56:14 | | Part LinusN |
15:56:24 | | Part kurzhaarrocker |
16:00 |
16:14:33 | | Join edx [0] (edx@p548792DE.dip.t-dialin.net) |
16:18:25 | | Join dwihno_ [0] (~dw@81.8.224.89) |
16:30:57 | | Quit dwihno (Read error: 110 (Connection timed out)) |
16:44:06 | *** | Saving seen data "./dancer.seen" |
16:54:24 | | Join methangas [0] (methangas@0x50a476c8.virnxx10.adsl-dhcp.tele.dk) |
16:54:24 | | Quit lImbus (Read error: 54 (Connection reset by peer)) |
17:00 |
17:06:59 | | Nick dwihno_ is now known as dwihno (~dw@81.8.224.89) |
17:16:35 | | Join dwihno_ [0] (~dw@81.8.224.89) |
17:24:32 | | Join lImbus [0] (~manuel@kernel.cycos.net) |
17:34:39 | | Quit dwihno (Read error: 110 (Connection timed out)) |
17:39:08 | | Join midk [0] (~midk@c-24-18-39-204.client.comcast.net) |
17:40:30 | | Quit midk|sleep (Read error: 104 (Connection reset by peer)) |
17:42:44 | | Join dwihno__ [0] (~dw@81.8.224.89) |
17:51:51 | | Join epictetus [0] (uifils@otto.microway.com) |
17:54:15 | | Join dwihno [0] (~dw@81.8.224.89) |
17:59:27 | | Quit hardeep ("[BX] Connection reset by panasync?") |
18:00 |
18:04:38 | | Quit dwihno_ (Read error: 110 (Connection timed out)) |
18:10:43 | | Quit dwihno__ (Read error: 110 (Connection timed out)) |
18:12:17 | | Join mecraw [0] (~lmarlow@69.2.235.2) |
18:32:22 | | Join bagawk [0] (Lee@ACC0E21B.ipt.aol.com) |
18:35:23 | Lynx_ | i just notices something weird: I had the flashed box charging while off. then I turned it on without unplugging it. now if i press off again it displays "battery charging", but that does not go away, and if i do something like move the cursor it smears through the message. |
18:35:37 | Lynx_ | like only the parts the cursor changes are refreshed. |
18:35:56 | midk | Lynx_, this was recently fixed |
18:36:03 | midk | upgrade to the latest daily build |
18:36:03 | Lynx_ | ok |
18:36:15 | Lynx_ | thx |
18:36:33 | midk | np |
18:39:44 | Lynx_ | hehe, the installer says "..while installing rockbox on your computer" |
18:41:03 | bagawk | :P |
18:41:15 | bagawk | the installer is a little wierd |
18:41:28 | midk | :) |
18:41:33 | bagawk | it also adds an item to your add/remove programs list |
18:41:34 | Lynx_ | didn't after upgrading, the box ask if it should rolo the new firmware? |
18:41:47 | bagawk | yes do that :) |
18:41:54 | Lynx_ | hehe, didn't even see that. and, does removing work? ;-) |
18:41:59 | Lynx_ | well, it's not asking |
18:42:02 | bagawk | i have no idea |
18:42:34 | midk | ? |
18:42:47 | bagawk | i think i just did it, without my archos connected, and it just said it was removed, with absolutly nothing done |
18:42:54 | midk | just rolo into the ajbrec.ajz |
18:44:10 | *** | Saving seen data "./dancer.seen" |
18:46:33 | Lynx_ | hmm, same with just unzipping it. maybe that feature was changed.. |
18:47:03 | midk | it sometimes doesn't work |
18:47:06 | midk | just do it manually |
18:47:35 | Lynx_ | i did... |
18:48:04 | midk | now reflash..... |
18:50:28 | | Join bagawk_ [0] (Lee@ACC06A2A.ipt.aol.com) |
18:50:45 | Lynx_ | thx, but I know that much ;-) |
18:51:13 | Lynx_ | with the video plugin, is there still some value one can adjust to remove flickering? |
18:51:44 | midk | nope |
18:51:57 | midk | let it warm up and it doesn't flicker though |
18:52:07 | midk | just a little band runs across the screen.. |
18:52:19 | | Quit bagawk (Read error: 104 (Connection reset by peer)) |
18:53:05 | | Nick bagawk_ is now known as bagawk (Lee@ACC06A2A.ipt.aol.com) |
18:55:18 | bagawk | midk: not always for me |
18:55:29 | bagawk | most of the time i see nothing |
18:55:44 | bagawk | :) |
18:56:04 | Lynx_ | is there some site where a rvf stuff is collected? |
18:56:15 | Lynx_ | like futurama and such... |
18:56:17 | bagawk | there are a few on the rocbkx site |
18:56:31 | bagawk | http://rockbox.haxx.se/newvid |
18:56:41 | bagawk | there are only a few good ones |
18:56:41 | midk | not really |
18:56:57 | midk | http://rockbox.haxx.se/newvid has a few things |
18:57:06 | bagawk | doom is ok, futruama is great, baby, and a warm reception in LA suck |
18:57:17 | bagawk | and grantz graf is kinda cool sometimes |
18:58:05 | Lynx_ | grantz graf? |
18:58:21 | Lynx_ | ah... |
18:58:43 | Lynx_ | and there is a wiki entry on the conversion tools |
18:59:08 | | Join pike [0] (amiga@h234n1fls22o1064.bredband.comhem.se) |
19:00 |
19:02:39 | Lynx_ | cu all |
19:02:45 | | Quit Lynx_ (" Like VS.net's GUI? Then try HydraIRC -> http://www.hydrairc.com <-") |
19:02:45 | pike | Hello Felix, Markus, Lee and anyone else I couldn't find the real name for :) |
19:08:52 | bagawk | ? |
19:09:09 | bagawk | do i know you? |
19:09:11 | bagawk | lol |
19:09:47 | pike | nah, I came here from your website |
19:09:57 | pike | did a little reading before |
19:10:00 | pike | :p |
19:10:28 | pike | so you guys involved in anyway with this? http://rockbox.haxx.se/twiki/bin/view/Main/IriverInfo |
19:16:00 | pike | just found this... shame I dont speak japanese http://www.susono.com/~hiroya_d/iRiverJ/Font/ |
19:18:07 | methangas | use babelfish |
19:18:19 | methangas | if you wanna find out what it can do |
19:18:33 | methangas | allthough i don't really have a solution to the firmware :P |
19:19:10 | pike | solution to what? |
19:20:00 | methangas | getting it translated |
19:21:01 | pike | aha.. I was just curious what it did. so anyone in here involved in getting rockbox onto ihpX series ? or it's still in the "need more info" stage ? |
19:21:58 | lImbus | i think they planned to buy a device |
19:22:26 | lImbus | 'they' found out it's the same usb-bridge |
19:22:27 | pike | most people in here swedes, or only the founders? |
19:23:00 | pike | they just cut the price further on ihp120 afaik. |
19:23:07 | pike | they = irivernordic |
19:24:42 | lImbus | a few of the founders/core developers are swedish. then there are germans, and a few from everywhere |
19:24:42 | lImbus | err. I actually think all of the founders are swedish |
19:25:12 | pike | so am I |
19:25:37 | pike | H120: förr 3795kr - nu 3499kr and thats directly from them, I think it can probably be found for as little as 3000 sek |
19:26:37 | pike | thats the unit I have myself, but I'm no viz with electronics, just know how to handle a primitive soldering iron :p |
19:28:55 | lImbus | tell it Zagor or Bagder. I dunno what they planned |
19:29:11 | | Quit pike (Read error: 104 (Connection reset by peer)) |
19:29:58 | | Join pike [0] (~amiga@h234n1fls22o1064.bredband.comhem.se) |
19:30:05 | lImbus | welcome back |
19:30:14 | pike | xchat crashed.. :p |
19:30:53 | | Join radu [0] (~radu@face-00000002.user) |
19:32:55 | pike | so when I read the documentation, the mp3 decoding hardware in the archos only supports mp3, this will probably not be an issue on iriver? |
19:40:43 | lImbus | yeah, you may be right. I know iriver can do other formats. so either the dsp does or they do in hardware (must have > 100 mHz) |
19:40:54 | lImbus | err, in software, of course |
19:41:13 | pike | cpu/dsp faster than 100mhz? |
19:42:06 | lImbus | cpu |
19:42:07 | pike | iriver ihpX handles wma, wav and mp3 afaik. no drm though |
19:42:39 | pike | dream would be lossless and aac support, hehe. but I'll say no more. too early to make wishes |
19:42:57 | lImbus | isn't wav lossless ? |
19:43:20 | bagawk | lImbus: yes but not compressed |
19:43:24 | pike | yeah, but I mean lossless compression, like flac, ape, you know |
19:43:35 | lImbus | ah, of course |
19:43:55 | lImbus | if they already to decoding in cpu, then we could give it a try. as well as ogg |
19:44:09 | lImbus | ogg depending on memory |
19:44:32 | pike | og yeah, firgot vorbis |
19:44:35 | pike | forgot* |
19:44:44 | pike | it's already supported |
19:44:51 | pike | but a real battery drainer |
19:46:19 | bagawk | bye |
19:46:22 | bagawk | : ) |
19:47:10 | | Quit bagawk ("umount /dev/brain") |
19:47:14 | pike | crappy decoder for vorbis methinks |
19:47:35 | pike | does rockbox support cuesheets handling now? |
19:53:03 | | Join hdn [0] (~TapeTape@dyn-83-157-167-218.ppp.tiscali.fr) |
19:53:06 | hdn | lut |
19:54:07 | lImbus | pike: what's a cuesheet ? |
19:54:32 | pike | it's an invetion that CDRWIN makers created |
19:55:05 | pike | it's a textfile basically desrcibing the layout for a cd, an instruction how it should be burned, with track separations etc |
19:55:37 | pike | past years have been used for "mixed" audiocd's, to provide "seamless" playback |
19:55:50 | pike | winamp supports it via a plugin |
19:55:54 | pike | foobar has the support builtin |
19:55:55 | midk | if you rip a cd as one huge mp3 file a cuesheet specifies times for each track, and names i believe etc |
19:56:04 | pike | ^yep |
19:56:13 | midk | at 3:17 it's track 2, 7:53 track 3 etc |
19:57:04 | pike | http://pike2k.mine.nu:8010/201-va_-_dont_look_now_mixed_by_way_out_west-boss.cue |
19:57:36 | | Part hdn |
19:57:48 | pike | that cuesheet is faulty |
19:57:54 | pike | ... the ending shouldnt be there. |
19:58:14 | pike | mp3 scene has issues with them, or better yet, the tools they use |
20:00 |
20:00:57 | lImbus | ok, I see. it takes consideration of pre and postroll |
20:02:06 | pike | "gaps" yeah |
20:02:20 | pike | now most cuesheets dont include this info, but some do |
20:09:50 | | Join webguest35 [0] (~0c01350a@labb.contactor.se) |
20:10:00 | | Quit webguest35 (Client Quit) |
20:10:20 | | Join webguest83 [0] (~0c01350a@labb.contactor.se) |
20:10:38 | webguest83 | hello |
20:11:54 | | Quit webguest83 (Client Quit) |
20:44:13 | *** | Saving seen data "./dancer.seen" |
21:00 |
21:03:44 | | Join Elemeno [0] (~4givn@dpc691997050.direcpc.com) |
21:04:05 | Elemeno | hey, has anyone ever replaced the LCD screen on the FM recorder? |
21:04:34 | midk | yes. |
21:04:57 | midk | oh, right, you were trying to replace yours. |
21:04:58 | midk | :) |
21:05:19 | Elemeno | :-) Yep |
21:05:29 | midk | having trouble? |
21:05:39 | Elemeno | I received the new one today, put it in, and it works! |
21:05:39 | Elemeno | But... I have a question |
21:06:20 | Elemeno | When I took the original one out, it seemed like it was glued or it somehow stuck to the MP3 player. so I'm wondering how I should reattach it |
21:06:48 | midk | your new one is loose? |
21:06:52 | midk | did you check the page then? |
21:07:43 | Elemeno | what I mean is the original screen, it seemed like the entire back was somehow glued or something to the white square |
21:08:00 | | Join _aLF [0] (Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net) |
21:08:01 | _aLF | hi |
21:08:07 | Elemeno | and it's just a practical question, I guess, of how to keep the new screen in place. does that make any sense? |
21:08:11 | Elemeno | hi |
21:10:47 | Elemeno | midk: Basically, I'm trying to figure out how to physically reattach the screen to the Archos once it's plugged in and working |
21:11:25 | midk | i know what you mean |
21:11:30 | midk | did you check the doc i gave you? |
21:12:31 | Elemeno | I think so. I know there was one page I visited that talked about replacing the LCD screen, but it was for a different model |
21:13:58 | midk | should be the same method, as it's the same screen |
21:14:11 | midk | you could just roll up a piece of tape and stick it back there :) |
21:14:33 | Elemeno | yup. I'm sure I could get creative. I was just wondering if there was "a way" |
21:14:48 | Elemeno | I'm pretty happy to just have my screen working again:-) |
21:16:55 | Elemeno | now I just have to fix the mic, but I wouldn't think that would be too bad |
21:17:22 | midk | not really a way :) |
21:21:27 | | Quit Elemeno () |
21:52:14 | | Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
21:52:25 | | Part scott666_ |
21:57:51 | | Quit midk (Remote closed the connection) |
22:00 |
22:31:52 | | Quit methangas (" The IRC Client of the Gods! -> http://www.hydrairc.com <- HydraIRC") |
22:44:16 | *** | Saving seen data "./dancer.seen" |
23:00 |
23:31:52 | | Quit lImbus (Remote closed the connection) |
23:47:56 | | Quit Hadaka (Read error: 238 (Connection timed out)) |