00:04:11 | preglow | indeed |
00:05:42 | | Quit noC|andY`fRa (Read error: 104 (Connection reset by peer)) |
00:07:58 | rasher | Hrm, the tables are not quite what they used to |
00:08:09 | Zagor | how so? |
00:08:20 | rasher | They're much darker now |
00:08:35 | rasher | Hm.. maybe |
00:08:45 | rasher | Maybe it's just because of missing styles |
00:08:47 | rasher | nevermind me |
00:08:49 | Zagor | darker? they are transparent now. |
00:09:01 | Zagor | or do you mean the header row? |
00:09:09 | rasher | Sorry, I meant the borders |
00:09:15 | Zagor | ah |
00:09:20 | rasher | rasher.dk/rockbox/WikiRescue/UsefulTools-r1.12%20-%2009-06.html">http://rasher.dk/rockbox/WikiRescue/UsefulTools-r1.12%20-%2009-06.html vs http://www.rockbox.org/twiki/bin/view/Main/UsefulTools |
00:09:57 | Zagor | right, the borders are slightly thicker now. |
00:12:07 | *** | Saving seen data "./dancer.seen" |
00:28:25 | preglow | looks all good to me |
00:29:00 | preglow | solved the registration problem? |
00:29:59 | Zagor | not yet |
00:30:30 | * | rasher chews on another page |
00:34:22 | | Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
00:34:36 | * | preglow nominates rasher for Dane of the Year |
00:39:59 | | Join ashridah [0] (i=ashridah@220-253-120-155.VIC.netspace.net.au) |
00:44:22 | rasher | when's the award show? |
00:45:03 | preglow | drammensveien 55, oslo, next weeken! |
00:45:07 | preglow | weekend, even |
00:45:34 | preglow | i'm actually going to denmark next weekend, we'll just do the awards ceremony there |
00:46:42 | rasher | Heh |
00:46:51 | | Join edx [0] (i=edx@p54A8677C.dip.t-dialin.net) |
00:50:42 | | Quit markun () |
00:51:39 | Zagor | registration works now |
00:52:46 | preglow | excellent |
00:52:54 | | Quit paugh ("Leaving") |
00:55:57 | | Quit ansivirus_ (Read error: 110 (Connection timed out)) |
00:56:09 | | Join bagawk [0] (i=1000@67-42-194-6.eugn.qwest.net) |
00:56:17 | | Join ansivirus_ [0] (n=ansiviru@ppp-69-148-94-58.dsl.rcsntx.swbell.net) |
00:58:03 | preglow | you didn't lose any of the mailing list info? |
01:00 |
01:00:36 | rasher | Zagor: how about the attachment weirdness? |
01:01:41 | Zagor | i'm looking at it but can't see what it is. looks like some incompatibility with the new twiki version. do we have any page where it works? |
01:02:02 | rasher | Erp.. that's not good |
01:02:15 | rasher | I could upload something to a test-page? |
01:02:24 | Zagor | please do |
01:03:43 | rasher | so now the ReleaseTodo page has an attachment |
01:03:57 | rasher | which.. doens't show up either |
01:04:00 | rasher | crikey |
01:04:56 | rasher | not releasetodo |
01:04:57 | rasher | hang on |
01:05:09 | rasher | ThingsTodo |
01:05:14 | rasher | http://www.rockbox.org/twiki/bin/attach/Main/ThingsTodo still nothing though |
01:06:03 | Zagor | very strange. i'll see what the code does. |
01:10:14 | bagawk | Zagor, Just curious, why did the mail list go down if rm -rf / was run, and the only permissions where for the wiki? |
01:10:44 | rasher | It was for the apache-user. Still curious though |
01:11:00 | rasher | why the mailing list would be deletable by www-data is weird |
01:11:01 | Zagor | lots of stuff was group-writable by this user, including the mailing list configs |
01:11:13 | rasher | ah |
01:11:21 | bagawk | I see |
01:11:55 | Zagor | they have to be for the web interface to work, iirc |
01:12:56 | | Nick ansivirus_ is now known as ansivirus (n=ansiviru@ppp-69-148-94-58.dsl.rcsntx.swbell.net) |
01:17:19 | preglow | oh? |
01:17:33 | preglow | isn't database stuff usually owned by dbuser:dbuser, btw? |
01:17:48 | preglow | or doesn't twiki store stuff in a db exclusively? |
01:18:03 | Zagor | no, each topic is an rcs file |
01:18:19 | preglow | ahhh |
01:18:31 | Zagor | lookie, attachments! |
01:18:41 | preglow | and there was much rejoicing |
01:18:54 | Zagor | there was indeed a change in the handling in this version |
01:20:47 | rasher | excellent |
01:21:40 | | Quit DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
01:23:57 | | Quit ashridah ("Leaving") |
01:25:54 | linuxstb | Is the following line of C correct? |
01:25:55 | linuxstb | if (inl(0x2000) == "gfCS") { ... |
01:26:26 | Zagor | no |
01:27:04 | linuxstb | Didn't think so. |
01:27:52 | rasher | 57 pages left.. |
01:28:11 | * | linuxstb needs to visit #ipodlinux |
01:28:26 | | Join Febs [0] (n=Febs@207-172-122-81.c3-0.rdl-ubr4.trpr-rdl.pa.cable.rcn.com) |
01:30:40 | | Quit ender` (No route to host) |
01:31:12 | Zagor | linuxstb: was that from ipodlinux code? |
01:31:31 | rasher | I'm guessing yes.. |
01:31:39 | linuxstb | Yes - the most recent CVS commit: http://cvs.sourceforge.net/viewcvs.py/ipodlinux/tools/ipodloader/tools.c.diff?r1=1.5&r2=1.6 |
01:31:54 | preglow | well |
01:32:04 | preglow | you'd need some pretty nifty magic for that code to work |
01:32:12 | preglow | since it compares two pointers... |
01:33:34 | Zagor | I assumed inl() returned a long |
01:33:49 | Zagor | ...which only makes it more weird |
01:33:49 | linuxstb | Me too. |
01:35:53 | preglow | well, you still compare something to an arbitrary pointer |
01:35:58 | preglow | which is pretty weird |
01:36:33 | Zagor | yes |
01:37:18 | linuxstb | Checking the IRC logs, someone on #ipodlinux spotted it as well. But it hasn't been fixed yet. |
01:37:30 | preglow | i wonder what the hell that line is supposed to do |
01:37:47 | preglow | whoever wrote it had to be seriously fscked up on something |
01:37:52 | rasher | It looks like completely black magic to me |
01:38:06 | linuxstb | rasher: That's ipodlinux :) |
01:38:31 | Zagor | likely address 0x2000 contains the longword equivalent of ascii "gfCS" on that particular target |
01:38:46 | linuxstb | Zagor: Yes, I think so. |
01:39:01 | rasher | It just seems so weird |
01:39:07 | linuxstb | inl is just a macro that reads from memory. |
01:39:08 | preglow | and... stupid... |
01:39:10 | rasher | and not even a comment.. |
01:39:32 | Zagor | committing code without even trying to compile it is kinda... icky too :-) |
01:39:36 | preglow | well |
01:39:39 | preglow | it will compile |
01:39:39 | rasher | /* DANGER, HERE BE MAGIC! */ |
01:39:41 | | Quit Moos (Read error: 110 (Connection timed out)) |
01:39:42 | preglow | no problem, perhaps a type error |
01:39:50 | preglow | warning, at best |
01:39:59 | | Quit xen` (Read error: 110 (Connection timed out)) |
01:40:13 | linuxstb | Yes, gcc gives the expected "tools.c:39: warning: comparison between pointer and integer" |
01:40:34 | preglow | but hell |
01:40:41 | preglow | people are so intent on ignoring warnings, it's no surprise |
01:40:59 | preglow | fixing a warning with a #pragma is accepted practice with a lot of people :/ |
01:46:46 | rasher | Zagor: Now I'm locked out :-X |
01:47:05 | Zagor | hang on.. |
01:47:33 | Zagor | now? |
01:47:39 | rasher | I'm in! |
01:47:50 | Zagor | slight mistake :-) |
01:54:19 | * | linuxstb finally has some iPod success. |
01:55:00 | preglow | elaborate :> |
01:55:41 | linuxstb | I simply got the ipodlinux bootloader to run the Apple firmware. |
01:56:39 | linuxstb | I'm just trying to work out exactly how much of my ipod ipodlinux supports. |
02:00 |
02:11:30 | rasher | Just start porting rockbox already |
02:11:52 | rasher | We're WAITING |
02:12:09 | *** | Saving seen data "./dancer.seen" |
02:14:08 | linuxstb | Patience. Maybe I should have bought myself an ipod that ipodlinux actually works on. |
02:14:45 | preglow | hrmph |
02:15:04 | preglow | should we put all the audio modifier stuff in the dsp layer or the pcmbuf layer of rockbox? |
02:15:26 | preglow | the dsp layer is the most logical place, but then there'll be a latency whenever you change a parameter, like mono processing to karaoke mode |
02:20:26 | | Quit bagawk ("Leaving") |
02:20:32 | Zagor | i'm off to bed. good night guys. |
02:20:39 | rasher | night |
02:22:06 | | Quit tvelocity ("Leaving") |
02:24:13 | preglow | perhaps a realtime mode, where we run at full cpu_boost all the time and with as little latency as possible, for use with such things as eq adjustment and pitch adjustment is possbiel |
02:24:26 | preglow | Slasheri: please come back to me on this if you read ;) |
02:25:10 | rasher | linuxstb: there's your cue |
02:25:59 | preglow | it'll be a pain for crossfading mode, of course, where you might have to risk dealing with 10 seconds of buffered pcm when you want to adjust the audio in some way |
02:27:43 | rasher | I just saw why running Linux on an ipod is silly. |
02:27:52 | rasher | "video playing has part of it in the kernel for various reasons" |
02:28:02 | rasher | that's so wrong |
02:28:42 | preglow | :/ |
02:28:45 | preglow | well, gotta bed |
02:28:46 | preglow | later |
02:28:53 | | Quit preglow ("feaches") |
02:43:35 | | Join Strath [0] (n=mike@dpc674681214.direcpc.com) |
02:45:25 | | Quit dpassen () |
03:00 |
03:09:17 | Febs | rasher, are you around? |
03:09:34 | rasher | barely, but yeah |
03:10:12 | Febs | What needs to be done to restore the wiki pages that you've cached? |
03:10:32 | Febs | Does all formatting etc. need to be reapplied? |
03:10:35 | rasher | Compare the current version to the cached html version, update what's changed in between |
03:10:46 | rasher | this pretty much means "write any changes in wiki syntax" |
03:10:52 | rasher | it's not a fun job.. |
03:11:02 | Febs | No, I imagine not. |
03:11:18 | Febs | I was afraid that's what you would say. |
03:11:25 | rasher | Some are easier than others of course |
03:11:31 | rasher | some have just had a line added/removed |
03:12:46 | Febs | I'm specifically looking right now at this page: rasher.dk/rockbox/WikiRescue/ManualRockboxInstall-r1.10%20-%2008-31.html">http://rasher.dk/rockbox/WikiRescue/ManualRockboxInstall-r1.10%20-%2008-31.html |
03:13:12 | Febs | I take it that I have to reapply all of the wiki syntax for hyperlinks, tables, headings, etc.? |
03:13:30 | rasher | Ah yes, you do indeed |
03:13:59 | rasher | Rewrite from scratch :-\ |
03:14:13 | Febs | Well, it could be worse. At least the text is preserved. |
03:15:24 | rasher | Yes. It'll just take some time |
03:16:55 | Febs | OK. I'll work on restoring some of the documentation pages that I wrote. |
03:16:57 | rasher | Just prod me if you fix any pages, and I'll remove them from the list |
03:17:01 | Febs | I will. |
03:42:11 | | Nick Sucka`away is now known as Sucka (n=NNSCRIPT@host81-156-157-185.range81-156.btcentralplus.com) |
03:47:11 | | Join pike [0] (n=user@c83-249-120-126.bredband.comhem.se) |
04:00 |
04:00:55 | | Join DarkShadow [0] (n=4360fb3a@labb.contactor.se) |
04:01:15 | DarkShadow | Hey. |
04:05:46 | | Join QT [0] (i=as@madwifi/users/area51) |
04:06:40 | DarkShadow | Hey. |
04:07:29 | Febs | rasher, ManualRockboxInstall has been restored. |
04:08:16 | rasher | Noted. |
04:12:12 | *** | Saving seen data "./dancer.seen" |
04:12:34 | DarkShadow | Where do you get rockboy files? Or are they some emulator file things that you have to own the game to have? |
04:17:01 | | Quit QT_ (Read error: 113 (No route to host)) |
04:25:28 | | Quit Sucka (Read error: 110 (Connection timed out)) |
04:26:01 | | Join Sucka [0] (n=NNSCRIPT@81.156.157.185) |
04:30:36 | | Quit cYmen ("zZz") |
04:35:35 | | Quit DarkShadow ("CGI:IRC") |
05:00 |
05:03:17 | | Quit Sucka ("a bird in the bush is worth two in your house") |
05:18:22 | | Quit JoeBorn (Nick collision from services.) |
05:19:07 | | Join jborn_ [0] (n=jborn@dsl017-022-247.chi1.dsl.speakeasy.net) |
06:00 |
06:12:13 | *** | Saving seen data "./dancer.seen" |
06:34:13 | | Join adiamas [0] (n=adiamas@ool-435559f8.dyn.optonline.net) |
06:35:26 | | Quit adiamas (Client Quit) |
06:37:04 | | Join adiamas [0] (n=adiamas@ool-435559f8.dyn.optonline.net) |
06:41:40 | | Quit adiamas ("Chatzilla 0.9.68a [Firefox 1.0.6/20050716]") |
06:52:13 | | Join LinusN [0] (n=linus@labb.contactor.se) |
06:56:07 | | Quit Maxime (Read error: 104 (Connection reset by peer)) |
06:56:31 | | Join Maxime [0] (n=flemmard@fbx.flemmard.net) |
07:00 |
07:25:17 | Bger | morning :) |
07:27:58 | Bger | rasher r u here ? |
08:00 |
08:05:17 | | Join ender` [0] (i=ychat@84.52.165.220) |
08:08:08 | | Join B4gder [0] (n=daniel@static-213-115-255-230.sme.bredbandsbolaget.se) |
08:12:14 | *** | Saving seen data "./dancer.seen" |
08:12:22 | Bger | morning, B4gder |
08:12:27 | B4gder | morning |
08:12:40 | Bger | wiki is up, afaics |
08:13:57 | Bger | i'm waiting for rasher to tell me which pages are already changed with last ones |
08:14:29 | B4gder | sounds like a fair approach |
08:15:29 | * | B4gder works on manually unsubscribing people |
08:22:01 | LinusN | people really can't read... |
08:23:59 | Bger | LinusN what do u mean ? |
08:24:38 | LinusN | they can't follow directions, they try to send the "unsubscribe" messages to the list instead of the list-admin |
08:28:28 | B4gder | 410 subscribers now |
08:40:06 | LinusN | http://www.rockbox.org/twiki/bin/view/Main/WikiRestore |
08:40:24 | | Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) |
08:41:39 | | Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
08:42:52 | | Quit linuxstb (Read error: 104 (Connection reset by peer)) |
08:42:57 | Bger | LinusN about the forensic analysis tool ... what did u use ? |
08:43:27 | | Quit linuxstb_ (Client Quit) |
08:44:46 | LinusN | Bger: sleuthkit and foremost |
08:45:08 | Bger | hm, i'll take a look at these, it's a nice to know thing ... |
08:48:16 | LinusN | i'll put up some links |
08:50:33 | Bger | i suppose there are such tools for reiserfs ? |
08:51:47 | LinusN | i dunno |
08:53:31 | | Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
09:00 |
09:05:48 | B4gder | I hate stupid mailers |
09:06:12 | B4gder | "Your mail to the following recipients could not be delivered because they are not accepting mail from daniel@rockbox.org" |
09:06:33 | B4gder | from a user on the mailing list |
09:06:47 | B4gder | do I need to say aol.com ? ;-/ |
09:12:36 | | Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
09:12:36 | Bger | B4gder : u've just added more spam to your mail ..:) |
09:12:36 | B4gder | I don't care |
09:12:36 | Bger | i see |
09:12:36 | B4gder | I get sooooooo much already |
09:12:36 | B4gder | btw: http://www.rockbox.org/twiki/bin/view/Main/RockboxOrgEmail |
09:12:36 | Bger | LinusN what about pdf files ? |
09:12:39 | LinusN | coming |
09:12:46 | Bger | good :) |
09:22:33 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
09:27:41 | linuxstb_ | Mmm. It appears that the latest color ipods (like mine) have a PP5022 in them, not a PP5020. |
09:28:50 | B4gder | probably to support the lcd |
09:32:37 | linuxstb_ | It's reported as "register compatible" with the PP5020 and there doesn't seem to be any ipodlinux specific code for the 5022 (just 5002 and 5020), so I don't think it's much of a problem. |
09:34:11 | Bger | but ipodlinux doesn't support ipod photo, or i'm wrong ? |
09:34:29 | linuxstb_ | Bger: It's "unsupported", but it works. |
09:34:47 | Bger | heh |
09:34:50 | B4gder | most models seem "unsupported" but working |
09:35:01 | linuxstb_ | Current status of ipodlinux is here: http://ipodlinux.org/Project_Status |
09:35:01 | Bger | so, u've got your ipod |
09:35:19 | linuxstb_ | Bger: Yes, but unfortunately it's one of the ones least supported by ipodlinux. |
09:37:23 | linuxstb_ | The only models which are unusable are the shuffle, Nano and the very latest revision of the color iPods. But I think it's just an LCD problem for the color iPods - at least, no-one has mentioned any other issues. |
09:42:28 | | Quit rasher (Remote closed the connection) |
09:47:38 | B4gder | now, what is the release waiting for really? |
09:49:30 | B4gder | its been 5 days since the latest archos related fix |
09:57:19 | LinusN | B4gder: amiconn has worked his ass off to find the recording bit-shift problem |
09:57:49 | B4gder | I know |
09:58:04 | B4gder | but how long will that take and do we really need it fixed before the release? |
09:58:24 | B4gder | isn't this a bug we've had like forever? |
10:00 |
10:00:55 | LinusN | yes |
10:03:03 | HCl | sounds like extra important to fix it |
10:03:04 | HCl | hi |
10:03:10 | linuxstb_ | I say lets give amiconn the decision - release now or wait for him. |
10:03:18 | B4gder | yes |
10:03:25 | LinusN | recovered pdf files online as well |
10:06:12 | Bger | hm, most of them must have been in the backup |
10:06:36 | linuxstb_ | LinusN: What about other filetypes - e.g. .zip or .exe (assuming there were any). |
10:07:12 | LinusN | coming... |
10:07:49 | B4gder | talk about doing rubbish, or is it making something out of rubbish? ;-) |
10:12:06 | LinusN | bmp images up |
10:12:17 | *** | Saving seen data "./dancer.seen" |
10:12:31 | LinusN | the recover tool must have problems with monocrome bitmaps |
10:12:43 | B4gder | I must go look for my cube gifs |
10:13:17 | LinusN | they are there |
10:13:23 | B4gder | they are? |
10:13:39 | B4gder | they're not on the gif page |
10:13:40 | LinusN | hmm, no :-( |
10:14:53 | B4gder | I think I still have them around |
10:22:02 | B4gder | there |
10:24:46 | | Quit ze (No route to host) |
10:36:49 | | Join Dma-Sc [0] (n=Dma-Sc@LAubervilliers-151-11-60-200.w193-251.abo.wanadoo.fr) |
10:37:40 | Dma-Sc | hi |
10:39:14 | | Join amiconn_ [0] (n=jens@p54BD42AD.dip.t-dialin.net) |
10:43:00 | | Quit linuxstb_ ("Leaving") |
10:57:23 | LinusN | zip files now online |
10:57:38 | | Quit amiconn (Read error: 110 (Connection timed out)) |
10:57:39 | | Nick amiconn_ is now known as amiconn (n=jens@p54BD42AD.dip.t-dialin.net) |
11:00 |
11:01:35 | Zagor | i went through the zips yesterday, renaming some to more useful names |
11:01:59 | Zagor | gifs and pngs too |
11:02:31 | LinusN | saw that |
11:04:24 | LinusN | Zagor: http://www.rockbox.org/twiki/bin/view/Main/WikiRestore |
11:05:07 | Zagor | yeah, found it |
11:05:21 | LinusN | did you move the png's? |
11:05:31 | LinusN | i didn't see any renamed png's |
11:06:01 | Zagor | maybe I only looked at them |
11:07:41 | Zagor | nice work on the pdfs. which tool did you use to snapshot the first page? |
11:10:17 | LinusN | imagemagick, of course |
11:10:32 | LinusN | wonderful tool |
11:10:53 | Zagor | aha. I didn't know it reads pdf too. |
11:11:08 | LinusN | convert xxx.pdf[0] -thumbnail 256x256 thumb_xxx.png |
11:11:28 | LinusN | i dodn't know it either, i just tried and it worked :-) |
11:11:29 | Slasheri | LinusN: btw, if you would like to have some remote rsync backup space (few gigabytes for example), i could provide that with 100 |
11:11:37 | Slasheri | + 100 Mbit/s connection |
11:11:40 | LinusN | it uses ghostscript for the pdf parsing |
11:11:43 | Slasheri | argh, weird enter.. |
11:11:56 | LinusN | Slasheri: thanks, but no thanks |
11:11:59 | Slasheri | ok |
11:12:09 | LinusN | we will make our own backup work |
11:12:21 | LinusN | and we only have a 2mbit/s connection |
11:12:46 | LinusN | shared with a lot of other sites |
11:28:09 | HCl | gee. |
11:28:18 | HCl | i don't trust the output of my perl converter script at all. |
11:28:25 | HCl | who's good at perl? |
11:30:22 | Zagor | what's the problem? |
11:31:53 | HCl | i wish i knew, heh. |
11:32:02 | HCl | ftp://titania.student.utwente.nl/rtd1tortd2.pl |
11:32:17 | HCl | its supposed to upgrade an runtime database v1 to runtime database v2 |
11:33:17 | HCl | maybe its just cause i forgot to close... |
11:33:54 | HCl | or not |
11:35:17 | HCl | forgetting to close was just one bug |
11:36:52 | B4gder | why add the "type" in the runtimedb? |
11:37:05 | HCl | to support empty hashes, and filehash upgrades |
11:37:28 | B4gder | ? |
11:37:36 | B4gder | why is that related to perl/java? |
11:38:04 | HCl | i figured it'd make sense to assign the perl algorithm a different number than the java algorithm since iirc they do not produce the same values |
11:38:18 | LinusN | they should |
11:38:42 | B4gder | crc32 on 32K data should be the same |
11:39:45 | B4gder | what happens when we support the C coded version? |
11:39:50 | HCl | the java version is attempting to be smart by skipping the id3 tag in mp3 files |
11:39:54 | B4gder | or if someone else decides to write one? |
11:40:07 | B4gder | HCl: and so does the perl version |
11:40:18 | HCl | they do not produce the same results though. |
11:40:32 | HCl | because the backends differ in quality of figuring out the id3 tag. |
11:40:57 | HCl | i don't really see why they should be the same anyways. |
11:41:11 | B4gder | because you lock the user into a single db |
11:41:16 | B4gder | db tool |
11:41:18 | B4gder | forever |
11:41:38 | HCl | why? |
11:41:57 | B4gder | what's the hash for? |
11:42:03 | HCl | i don't see how we're doing that, at least, not with the hashtype upgrade. |
11:42:06 | B4gder | if the hash can differ, then what's the point? |
11:42:21 | B4gder | right, you need to run a conversion tool if you decide to build a new db |
11:42:24 | HCl | thats one of the reasons why the hashtype field is getting added. |
11:42:36 | B4gder | then what type do I use when I write my new db tool? |
11:42:47 | HCl | depends on how compatible it is with the rest. |
11:43:05 | HCl | if its 100% compatible with say, perl, then the perl type. |
11:43:08 | B4gder | I say it is the wrong way out of this problem |
11:43:48 | HCl | then propose a better one :) |
11:43:57 | HCl | while at the same time solving the 0 crc problem |
11:43:59 | B4gder | sure - make them produce the same crc |
11:44:06 | LinusN | make the two tools produce the same hash |
11:44:10 | B4gder | the 0 crc is not depending on what version you use |
11:44:14 | HCl | and exactly how do you propose to do that :) |
11:44:19 | B4gder | HCl: debugging? |
11:44:21 | HCl | and exactly how do you propose future hash upgrades? :) |
11:44:28 | B4gder | uh? |
11:44:37 | B4gder | you mean when you change hash algo? |
11:44:38 | HCl | in the future, we'll want to hash on the music data |
11:44:41 | HCl | yes. |
11:44:56 | LinusN | what do we hash now? |
11:45:03 | B4gder | then you change db version |
11:45:04 | HCl | the first 32kb, including id3 tags. |
11:45:16 | HCl | and then destroy everyone's runtime database? |
11:45:18 | HCl | i'd think not. |
11:45:20 | | Join ashridah [0] (i=ashridah@220-253-120-220.VIC.netspace.net.au) |
11:45:26 | LinusN | then how can the two tools produce different hashes? |
11:45:29 | B4gder | no, and convert it to the new |
11:46:04 | B4gder | the perl version already checksums the audio data |
11:46:06 | HCl | well, be my guest in either altering the perl or the java version in producing the equivalent of the other |
11:46:12 | HCl | in the meanwhile |
11:46:19 | HCl | i'll just use my own approach on my local tree. |
11:46:29 | LinusN | HCl: how cooperative |
11:46:40 | HCl | sorry, but i'm not going to fix the java or perl version |
11:46:43 | HCl | into generating the same hash. |
11:46:50 | HCl | because i hate perl |
11:46:56 | HCl | and the java one relies on a backend |
11:47:03 | HCl | and though its completely open source with the source available |
11:47:05 | B4gder | so you want to bury the bugs by creating an additional tool layer? |
11:47:12 | HCl | i am not going to figure out how it works, black box principle and such. |
11:47:40 | B4gder | sounds insane in my ears |
11:47:42 | HCl | i personally think its better to support different type of hashes in the database itself |
11:48:10 | B4gder | possibly, but these should not be different types |
11:48:14 | LinusN | HCl: because you don't want to fix bugs? |
11:48:18 | B4gder | we have a defined way |
11:48:21 | B4gder | a defined format |
11:48:29 | HCl | LinusN: because i want to support upgrading hash algorithms |
11:48:29 | B4gder | either we follow the format, or we don't |
11:48:45 | HCl | you can change the java and perl version back to hashing the first 32k if you want |
11:48:50 | HCl | they'd be equivalent then. |
11:49:01 | HCl | but worse, obviously. |
11:49:17 | B4gder | then I say we dump the java way and we won't have this problem |
11:49:34 | HCl | heh, good luck |
11:49:47 | HCl | i'm not going to write a perl version to generate the database |
11:49:59 | B4gder | I already did |
11:50:00 | HCl | and the java version is already superior to the perl version |
11:50:06 | LinusN | how? |
11:50:15 | HCl | LinusN: its id3 reading backend is much better. |
11:50:24 | HCl | the perl version generates crap pYi things |
11:50:27 | HCl | in the database |
11:50:33 | LinusN | oh, a bug |
11:50:34 | B4gder | but we fix bugs in the perl version |
11:50:39 | B4gder | you refuse to do so in the java one |
11:50:53 | B4gder | you want to hide them instead |
11:51:05 | HCl | the java version doesn't do that |
11:51:05 | HCl | i 'm not going to fix bugs in code that other people wrote and isn't transparaent, no. |
11:51:08 | HCl | i don't want to hide them. |
11:51:21 | LinusN | transparent? |
11:51:24 | HCl | i want to upgrade the hashing algorithm to rely on music data |
11:51:28 | HCl | that, yes. i'm lagging tons |
11:51:40 | B4gder | we already checksum music data |
11:51:49 | HCl | but not consistently. |
11:51:55 | B4gder | then that's a bug |
11:52:10 | HCl | the difference between perl and java |
11:52:15 | HCl | is *not* the reason for the database update |
11:52:31 | HCl | the reason is to support database hash upgrades |
11:52:42 | HCl | easily |
11:52:47 | LinusN | and to support "no hash" instead of crc=0 |
11:52:50 | HCl | without having to bump the runtime database version all time |
11:52:50 | HCl | yes. |
11:53:44 | B4gder | do we really need to do hash upgrades? |
11:54:11 | B4gder | I can see how we should support CRC == 0, but not why we'd need to change hash |
11:54:27 | HCl | unless we have a perfect hashing algorithm that hashes on music content, i can see how we'll have to upgrade it a few times |
11:54:30 | HCl | on top of that. |
11:54:39 | HCl | since we need to support crc == 0 in the first place |
11:54:47 | HCl | we have an extra field in the database anyways |
11:54:50 | HCl | that we can use for hashtypes |
11:55:07 | HCl | and thats simply 0 for no hash. |
11:55:47 | | Join tvelocity [0] (n=tony@ipa221.7.tellas.gr) |
11:55:56 | B4gder | and when used, it is "crc32 on music" |
11:56:06 | B4gder | on 32K of music even |
11:56:19 | HCl | we don't have that reliably implement. |
11:56:21 | HCl | implemented |
11:56:22 | LinusN | ok, so the perl code has trouble finding the music content |
11:56:23 | LinusN | ? |
11:56:27 | HCl | both the perl and the java versions |
11:56:32 | HCl | have trouble finding the music content |
11:56:36 | HCl | in certain files |
11:56:44 | B4gder | they may have bugs |
11:56:52 | HCl | in some situations the perl version does better finding the music content |
11:56:54 | B4gder | but the perl version does as described |
11:57:01 | HCl | and in some situations the java version does better at finding the music content |
11:57:12 | HCl | and the perl version has id3 tag bugs |
11:57:15 | HCl | that the java version doesn't have |
11:57:35 | Zagor | wouldn't the simplest way be to always read the 32KB from the middle of the file? the beginning is hardly the most unique part. |
11:57:42 | LinusN | then i suggest we either 1) fix the content-finding bugs or 2) read the hash data from 128k into the file |
11:57:44 | Zagor | and there's not many tags in the middle |
11:57:49 | B4gder | think sounds like a reason to reconsider the crc idea |
11:57:55 | B4gder | this sounds |
11:58:03 | HCl | we already discussed that zagor, the middle changes because the id3v2 tag data is at the front |
11:58:05 | B4gder | I like the 128K idea |
11:58:10 | HCl | the same goes for 128k |
11:58:12 | HCl | not reliable |
11:58:17 | HCl | the amount of data in the front changes |
11:58:22 | HCl | when id3v2 tags are changed |
11:58:25 | LinusN | ah yes |
11:58:32 | Bger | middle 128k ? |
11:58:38 | Zagor | ok, we want to be "tag agnostic" |
11:58:44 | B4gder | and tool agnostic |
11:58:46 | LinusN | tagnostic |
11:58:48 | Zagor | right |
11:59:03 | Bger | middle of frame data |
11:59:05 | Bger | ? |
11:59:05 | LinusN | so we should fix the bugs then |
11:59:20 | | Quit B4gder ("Lämnar") |
12:00 |
12:00:16 | LinusN | so both tools find the same music content |
12:00:31 | HCl | i agree |
12:00:55 | HCl | for the java tool, this probably means writing some code to properly find the location of music data in an mp3 / ogg |
12:01:05 | HCl | i've been wanting to get rid of the icky backend that does it for it now |
12:01:20 | HCl | i also need samplelength and playlength though |
12:01:36 | HCl | which is annoyingly tricky to get |
12:02:13 | HCl | anyways |
12:02:16 | HCl | i gotta go |
12:02:17 | HCl | bbl |
12:12:19 | *** | Saving seen data "./dancer.seen" |
12:13:30 | LinusN | gotta go too |
12:13:33 | | Part LinusN |
12:17:07 | | Join linuxstb [0] (n=d57b9aa9@labb.contactor.se) |
12:18:29 | linuxstb | Talking about the tag database, we now have a reasonably good implementation of file/tag parsers in apps/metadata.c Why don't we just use that and convert the generator to C? |
12:19:59 | linuxstb | Also, FLAC and (I think) wavpack already have an md5sum of the entire uncompressed PCM data stored in the metadata - could that be used as a hash? |
12:20:52 | Zagor | if reliable, then sure |
12:24:15 | linuxstb | If you're talking about the md5sum, then AFAIK it's part of the FLAC spec, so must be correct in a valid FLAC file. I would expect wavpack to be the same. |
12:24:47 | linuxstb | But it's 128-bit - I'm guessing that will be an issue. |
12:24:53 | | Quit tvelocity ("Leaving") |
12:58:21 | | Join amiconn_ [0] (n=c1af49cb@labb.contactor.se) |
12:59:08 | amiconn_ | hi |
12:59:17 | Bger | hi, amiconn |
13:00 |
13:04:15 | linuxstb | How are your recording tests going? |
13:05:25 | amiconn_ | Not too well :/ |
13:05:29 | amiconn_ | gtg |
13:05:32 | Bger | :( |
13:05:58 | | Quit amiconn_ ("CGI:IRC (EOF)") |
13:06:48 | | Join webguest83 [0] (n=5638891c@labb.contactor.se) |
13:10:10 | | Join preglow [0] (n=thomjoha@hekta.edt.aft.hist.no) |
13:23:24 | | Join rasher [0] (n=jonas@62.79.64.148.adsl.hs.tiscali.dk) |
13:23:57 | Bger | rasher ? |
13:24:10 | rasher | Yup |
13:24:32 | Bger | what pages are already updated? |
13:24:37 | Bger | in the wiki |
13:24:50 | rasher | Anything that isn't on my page |
13:25:17 | rasher | Well, and a few more, I've not updated it since last night |
13:29:55 | rasher | Check the page now |
13:30:01 | rasher | rasher.dk/rockbox/WikiRescue/">http://rasher.dk/rockbox/WikiRescue/ |
13:31:44 | Bger | ok |
13:34:07 | preglow | anyone got any clever ideas on how to handle audio modifications without heaps of latency on rockbox? |
13:37:31 | Bger | the changelog is BIG... |
13:38:04 | Zagor | I think we need a "digested" version for the average user |
13:38:38 | linuxstb | preglow: What kinds of audio modifications are you talking about? |
13:38:55 | rasher | Zagor: That's what I intended the releasenotes "what's new" section to be |
13:38:59 | rasher | I should update these.. hang on |
13:39:35 | preglow | linuxstb: eq, replaygain, stereo width, etc |
13:39:57 | linuxstb | Just normal playback processing then? |
13:40:34 | preglow | linuxstb: when changing a parameter and having the processing in dsp.c, you might have to wait the entire length of the audio buffer (which can be VERY long for crossfading modes) before you can hear the result of your change |
13:41:02 | linuxstb | OK, I understand the problem. |
13:41:16 | webguest83 | hi - i have a problem with recordings - the same as in bug [ 1152291 ] - has there been a bugfix for that? |
13:41:36 | preglow | the other option is applying the processing right before the audio is sent to the dac, but then it's already been reduced to sixteen bits, and a lot of precision will vanish in subsequent processing |
13:42:04 | linuxstb | preglow: And the audio in the buffer could be from different tracks - so different resampling and replaygain would be needed. |
13:42:29 | preglow | never thought about that |
13:43:27 | Bger | rasher : how is the "checkmart" in wiki lang ? |
13:43:33 | Bger | checkmark |
13:43:40 | rasher | %Y% |
13:45:27 | preglow | might actually need to buffer the data in 32 bit format and apply dsp processing at the other end of the buffer :/ |
13:46:27 | linuxstb | Is it common to change the DSP parameters during playback? Can't we just flush the buffer? |
13:47:38 | preglow | well, that's what i thought about as well |
13:47:55 | preglow | and that might fail for a slow codec |
13:48:07 | preglow | especially if other stuff is going on, like loading |
13:48:36 | preglow | changing a parameter sometimes requires a bit of extra prccessing as well, like for eqs |
13:48:58 | linuxstb | I don't know if this affects what you are thinking about now, but I would like Rockbox to be able to output PCM data at the native samplerate on targets that allow it (such as ipod). |
13:49:41 | linuxstb | Obviously if cross-fade was enabled, we would probably have to resample everything. |
13:50:48 | preglow | i think rockbox should be able to do this now as well, for those sample rates where it's possible for spdif out, or for all frequencies when spdif out is disabled |
13:51:06 | | Join muesli- [0] (i=muesli_t@Bbc60.b.pppool.de) |
13:51:34 | linuxstb | So does the iriver spdif out support different samplerates? |
13:52:49 | preglow | yeah, but not certain which of them are actually possible |
13:53:32 | Bger | ChangeLog->General Section ok :) |
13:53:40 | preglow | i know of 48000, 44100 and 32000 |
13:53:41 | preglow | might be more |
13:55:11 | rasher | Bger: don't bother with it - I have a completely up to date version of it lying arount |
13:55:24 | Bger | eh :( |
13:55:39 | rasher | sorry I missed that |
13:55:52 | muesli- | re |
13:56:09 | Bger | rasher : so, where to start from ? |
13:56:28 | Bger | HowtoUpdateLangfile ? |
13:56:56 | rasher | that's fine.. don't bother fiddling with the list at the bottom |
13:57:03 | rasher | if the rest is correct, don't touch it |
13:57:11 | rasher | I have a script that outputs the list at the bottom |
13:57:45 | Bger | i didn't understand what do you want to say ... |
13:57:47 | rasher | you're picking all the wrong ones! |
13:58:14 | Bger | ok, give me topics to work on |
13:58:34 | rasher | Well.. anything but ChangeLog and HowtoUpdateLangfile really |
13:58:41 | Bger | hahaha :) |
13:59:26 | Bger | ok, i must join in the lottery today for sure ... |
13:59:31 | rasher | Heh |
14:00 |
14:02:33 | preglow | oh well, i should talk to slasheri about this |
14:03:56 | Bger | rasher IaudioX5Info ... i created nearly empty page, see your wiki rescue and u'll understand why... |
14:05:09 | rasher | It *was* a nearly empty page except for a few image.. not much to do about that |
14:05:18 | rasher | there's a typo though |
14:05:48 | Bger | correct me :) |
14:05:57 | rasher | No, in my rescue page I meant |
14:06:10 | rasher | it said the cache I had was r1.2, but it was in fact 1.12 |
14:06:37 | Bger | yep |
14:08:14 | | Join noC|andY`fRa [0] (i=andy@dsl-084-058-111-005.arcor-ip.net) |
14:10:54 | Bger | rasher : what to do with the nonexisting links in text ? |
14:11:09 | Bger | like %ATTACHURL%/decoded.gig |
14:11:15 | Bger | s/gig/gif |
14:11:58 | rasher | I've just put the filename in red |
14:11:59 | rasher | so |
14:12:09 | rasher | %RED%decoded.gif%ENDCOLOR% |
14:12:20 | *** | Saving seen data "./dancer.seen" |
14:12:21 | rasher | should make it stand out for people going over the pages |
14:12:46 | | Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
14:14:27 | Bger | ok, clear |
14:15:02 | | Part webguest83 |
14:15:17 | rasher | Which page? |
14:16:43 | Bger | last edited :) |
14:16:46 | preglow | where does one adjust the custom stereo configuration? |
14:22:00 | | Join DeepB [0] (n=joe@66.90.73.214) |
14:24:22 | | Quit pike () |
14:26:55 | Bger | rasher InsideMPIOHD200 done |
14:27:19 | rasher | Ok |
14:27:23 | | Join Moos [0] (i=DrMoos@m113.net81-66-159.noos.fr) |
14:28:21 | Bger | IpodLinux done also |
14:28:31 | Moos | Good day all! |
14:29:33 | Moos | congratulations for the speed recovering Wiki |
14:29:41 | Febs | Ugh, I am not looking forward to recreating the FileMenu and MainMenu wiki menu pages! |
14:31:13 | Febs | Using many tables and cross-links seemed like a good idea when I first created it ... not so much fun to re-do, however. |
14:32:11 | Febs | At least it will give me the opportunity to do something that I've been meaning to do for a while, and add some screen shots. |
14:32:38 | Moos | hehe :) |
14:38:17 | Bger | IriverBDM done |
14:43:10 | rasher | 44 pages to go. |
14:43:30 | * | Bger will talk with his gf for a while |
14:45:45 | * | Bger notices the bullsh*ts in IriverH3XXXComp..., he wrote 2-3 months ago :) |
14:47:18 | rasher | Erp.. the "view raw" links are now displayed in a text-field.. will searchengines cache that? |
14:47:27 | * | rasher is thinking if this happened again |
14:47:56 | muesli- | Bger its a never ending story, never look back what you have done before ;-) |
14:49:41 | Bger | :P |
14:56:09 | Zagor | rasher: i think they will, yes |
14:56:34 | Zagor | but I wouldn't say it's a great improvement |
14:56:52 | | Quit Seed (Nick collision from services.) |
14:56:53 | | Join Seedy [0] (i=ben@l192-117-115-168.broadband.actcom.net.il) |
14:57:15 | | Quit Dma-Sc ("What?! Open source isn't good enough for you? Bersirc 2.2 [ http://www.bersirc.org/ - Open Source IRC ]") |
14:57:41 | | Join bobTHC [0] (n=bobTHC@62.34.141.55) |
14:57:48 | bobTHC | hi folks !! |
14:58:07 | Moos | Bonjour bob |
14:58:14 | bobTHC | :) |
15:00 |
15:02:15 | | Quit noC|andY`fRa (Read error: 104 (Connection reset by peer)) |
15:09:56 | | Quit Febs (Read error: 110 (Connection timed out)) |
15:18:06 | HCl | linuxstb: darn, thats pretty sweet |
15:18:11 | HCl | about flac/wavpack |
15:20:20 | linuxstb | Is a 128-bit checksum going to cause you problems though? |
15:21:50 | linuxstb | Also, am I right in thinking you create a checksum of the first 32K of the compressed music data? What if the track starts with silence - isn't there a big chance of a collision? |
15:22:46 | rasher | linuxstb: I investigated this.. on my entire collection, using the first 512 *bytes* was enough to avoid collisions |
15:23:09 | linuxstb | Did that include the ID3 headers though? Which filetype(s) are in your collection? |
15:23:17 | rasher | Of course, I don't have any WAV files beginning with perfect silence |
15:23:38 | rasher | I'm not sure, I *think* I skipped id3 headers, but I'm not sure |
15:23:44 | rasher | mix of mp3/ogg |
15:23:49 | rasher | about 80/20 |
15:24:47 | linuxstb | I quite often edit MP2 radio recordings by splicing pre-encoded about 2 seconds of silent MP2 frames to the beginning. |
15:25:05 | rasher | What the.. no PluginSolitaire in the wiki? |
15:25:25 | linuxstb | This is about 83 frames at 576 bytes each - so more than 32K. |
15:25:56 | rasher | I was advocating first+last X bytes, but that was ruled out because of increase disk-seeking |
15:27:04 | Zagor | i still think (file_size-tag_size)/2 + tag_size is a good position |
15:32:43 | linuxstb | Zagor: I agree - the middle of the compressed data is a good place. Or simply just the middle of the file. |
15:32:54 | linuxstb | It's also possible to pad the end of a track with silence. |
15:33:04 | rasher | filesize/2 should be fine? |
15:33:26 | linuxstb | I suppose we want to guarantee we are not including any metadata tags. |
15:33:28 | rasher | it's not like the tag_size is significant compared to the filesize |
15:33:53 | linuxstb | rasher: It shouldn't be, but I think some people do odd things with id3v2 tags |
15:34:36 | rasher | Embedded music video! |
15:40:34 | preglow | ahahahha |
15:43:27 | preglow | determining the tag size will probably require even more seeking, though |
15:43:55 | HCl | i agree with zagor, though eventually we might want a hash of the uncompressed pcm data |
15:44:32 | HCl | i had collissions with the first 512 bytes |
15:44:45 | HCl | as for the 128bit nature |
15:44:51 | HCl | we'll just have to somehow scale it down |
15:45:10 | HCl | either that or add an 128bit hash support to the database |
15:45:54 | preglow | scaling down a hash is badness |
15:46:07 | HCl | well |
15:46:15 | preglow | it very much defeats their purpose |
15:46:20 | HCl | i personally don't see too much problems with increasing the hash size in the database |
15:46:26 | HCl | but i don't know about other people. |
15:46:30 | preglow | that's what should be done |
15:46:30 | preglow | definitely |
15:46:46 | HCl | okay, so 128bit hash, as well as a field to say whether there is a hash or not? |
15:47:02 | preglow | perhaps a hash/checksum type field, describing size and type :> |
15:47:08 | preglow | where 0 means no hash |
15:47:10 | HCl | thats what i suggested |
15:47:16 | HCl | but some people were highly against it |
15:47:20 | preglow | why? |
15:47:21 | HCl | for reasons still fairly unknown to me. |
15:47:28 | HCl | i dunno. |
15:47:45 | Bger | rasher: IriverH3XXHardwareComponents done |
15:47:45 | HCl | Bagder: ? |
15:48:24 | linuxstb | If we are going to support "native" checksums like the FLAC/Wavpack md5sum, then a "hash type" field does make sense - different kinds of hashes for different kinds of files. |
15:48:27 | rasher | Bger: ok |
15:49:07 | HCl | well i'm glad my idea and implementation isn't totally rejected :p |
15:49:12 | HCl | just need to upgrade the hash size |
15:49:24 | rasher | 35 wikipages left. |
15:52:23 | * | Bger hopes that the backup system will be working very soon again |
15:55:34 | preglow | anyone know why Lear says the ogg proglem has only been partially fixed? assuming there's enough memory for malloc and there are no leaks, i'd think it should work very well now |
15:57:52 | Bger | rasher i hard can see any difference between IriverHardwareComponents rev 1.51 (in the wiki) and 1.52 (rescued) |
15:58:04 | rasher | I'll see |
15:58:04 | Zagor | Bger: i'm doing manual backups now until things are in order again |
15:58:13 | Bger | nice |
15:58:16 | | Quit ender` (Read error: 110 (Connection timed out)) |
15:59:09 | rasher | ah.. that's a tough one :-\ |
16:00 |
16:00:31 | | Join muesli__ [0] (i=muesli_t@Bc0a8.b.pppool.de) |
16:01:02 | Bger | maybe a typo ?:) |
16:01:37 | rasher | No |
16:01:41 | rasher | (F)P22AD-LVX245 is changed |
16:02:25 | rasher | and that's it |
16:02:33 | rasher | two places |
16:02:42 | Bger | only one |
16:02:49 | Bger | the other is %TOC% |
16:03:03 | rasher | ah okay |
16:03:05 | Bger | just renamed (F) to fairchild |
16:03:11 | Bger | ok, i'll rename it |
16:03:43 | Bger | i was checking tables, text ... |
16:04:02 | Bger | ohm resistance ... :) |
16:04:08 | preglow | hmm, i need to call apps/dsp.c code from firmware/sound.c, is that even possible? |
16:05:13 | Zagor | no |
16:05:21 | preglow | then dsp.c needs to be in firmware/ |
16:05:37 | linuxstb | Or sound.c needs to be in apps? |
16:05:41 | preglow | perhaps |
16:05:57 | preglow | but all the audio stuff for iriver is in apps now |
16:07:13 | preglow | and to implement the 'stereo width' and 'channels' settings, i need to do work in dsp.c |
16:07:27 | preglow | but the interface is in firmware/sound.c :/ |
16:09:39 | | Quit muesli__ (Read error: 104 (Connection reset by peer)) |
16:09:53 | rasher | Zagor: erp, locking is 60 minutes now.. could we lower it to 30 minutes? |
16:10:04 | * | rasher summons Febs |
16:10:44 | Bger | IriverIfpPort done |
16:10:59 | rasher | okay |
16:11:03 | Bger | hah how does this sound :) |
16:11:19 | linuxstb | preglow: That must be because some targets can do it in hardware. So it seems that dsp.c should belong in firmware - because it duplicates functionality provided by hardware on some targets.. |
16:11:25 | Bger | "i just saw in the irc log that Rockbox already runs on iriver ifp" .... |
16:11:57 | preglow | linuxstb: yes, i agree |
16:12:01 | linuxstb | Similarly, some hardware will not need samplerate conversion. |
16:12:08 | linuxstb | etc etc. |
16:12:21 | *** | Saving seen data "./dancer.seen" |
16:12:42 | preglow | i really think stuff like pcmbuf belongs in firmware as well, heh |
16:12:46 | preglow | it's pretty lowlever |
16:12:49 | Bger | IriverInstall is large :( |
16:12:50 | preglow | lowlevel, even |
16:17:58 | preglow | the playback speed change i want to do also needs to have it moved, hrmph |
16:18:56 | | Join ender` [0] (i=ychat@84.52.165.220) |
16:20:48 | linuxstb | preglow: firmware/ sounds the right place to me. |
16:21:49 | Zagor | rasher: NonArchos done. found among recovered files. |
16:21:58 | Bger | rasher : after ~ 10 min i'll go offline, so i WONT finish IriverInstall |
16:22:52 | rasher | Bger: okay.. just save it locally and work on it when you get the time |
16:22:55 | rasher | Zagor: noted |
16:23:16 | Bger | rasher: i'll go home, and will continue to work on it tomorrow |
16:23:35 | rasher | Okay |
16:23:40 | rasher | only 26 left! |
16:23:59 | Bger | good :) |
16:24:10 | Bger | u're definitely quicker than me ;) |
16:24:37 | rasher | I pick the easy targets, I think |
16:25:24 | | Quit muesli- (Read error: 110 (Connection timed out)) |
16:26:58 | Bger | this iriverinstall is written for idiots ... |
16:28:20 | preglow | well, you can't rule out them when writing docs, now can you |
16:28:46 | * | preglow tries moving dsp.x and sees what happends |
16:29:55 | Zagor | most of the undeleted files are broken. i find fragments of the files mixed with each other. often the same fragment in multiple files. frustrating. |
16:30:24 | preglow | yes, that's usually the case |
16:30:37 | preglow | i recovered a whole harddrive once, most of it was intermingled rubbish |
16:30:44 | * | preglow summons Slasheri |
16:31:03 | Bger | rasher: what's the wiki code for the "idea's lamp" ? :) |
16:31:21 | preglow | linuxstb: if i move dsp to firmware, the entire playback subsystem has to move as well, it seems |
16:31:54 | Zagor | preglow: might be a good time to step back and rethink the layers. |
16:32:01 | preglow | now, why the flaming hell are the DSP_ constants in _playback.h_ |
16:32:16 | Zagor | the ones we have are very old and not designed for what we do today |
16:32:38 | preglow | i still think they're ok |
16:33:03 | Zagor | in general, yes. but some parts might need to be adjusted more than just "i'll move this here and this there" |
16:33:16 | preglow | sure |
16:33:20 | preglow | i'm just giving things a try now |
16:33:55 | preglow | if it's possible to just do a straight move, it's a solution that'll actually work for now and changes more or less nothing |
16:34:41 | rasher | Bger: hrm, %T% maybe (Tip) |
16:35:57 | rasher | Bger: they're defined here: http://www.rockbox.org/twiki/bin/view/TWiki/TWikiPreferences |
16:36:19 | linuxstb | preglow: It would be nice if you had to move some code out of playback.c - it's getting far too big IMO. |
16:36:28 | Bger | ok, found it |
16:36:30 | Bger | never mined |
16:36:31 | Bger | mind |
16:36:34 | preglow | i don't think i'm up too a big code restructuring, i'm very bad at that |
16:36:35 | Bger | gotta go |
16:36:45 | Bger | IriverInstall is ready up to "STEP 4" |
16:36:51 | rasher | have you saved it? |
16:36:54 | Bger | yes |
16:36:58 | Bger | and it's unlocked |
16:37:02 | rasher | I'll finish then |
16:37:14 | Bger | as u wish |
16:37:25 | Bger | if you don't do it, i'll finish it tomorrow |
16:37:28 | Bger | bye |
16:37:32 | rasher | bye |
16:37:36 | rasher | thanks for the help |
16:37:43 | Bger | heh |
16:37:53 | Bger | thanks 2 u to |
16:37:55 | Bger | o |
16:38:26 | Bger | i don't think we must thank each other, everyone does this for all:) |
16:38:29 | preglow | but indeed, playback.c has grown horribly |
16:40:05 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
16:41:17 | preglow | Bger: still, hearing that ones work is appreciated from time to time is nice |
17:00 |
17:01:07 | Slasheri | preglow: hi. Hmm, why would you ever want to move dsp part to firmware? |
17:01:46 | Slasheri | even pcmbuf is not a firmware layer (which is used by dsp) |
17:02:00 | preglow | Slasheri: because i need to interface with stuff in firmare/ |
17:02:06 | preglow | like stereo width, channel settings |
17:02:12 | preglow | firmware code can't call app code |
17:02:12 | | Join Sucka [0] (n=NNSCRIPT@host81-156-157-185.range81-156.btcentralplus.com) |
17:02:15 | Slasheri | Ah, hmm.. |
17:02:24 | Slasheri | can you write an api to interface with that? |
17:02:34 | Slasheri | i think dsp shouldn't need directly to access them |
17:03:09 | preglow | well, i could pepper the apps/ code with ifdefs to call firmware code in the case of archos, and apps code in the case of iriver |
17:03:12 | preglow | but i think that's wrong |
17:03:22 | Slasheri | hmm, yes.. |
17:04:49 | preglow | the archos/iriver stuff really needs to be unified by some brave soul :/ |
17:05:05 | | Quit ashridah ("Leaving") |
17:05:52 | preglow | and there's another thing i'd like to ask your opinion about |
17:06:04 | Slasheri | i think the mpeg.c needs to split into firmware and application layers.. |
17:06:26 | Slasheri | but now some food -> |
17:06:43 | preglow | todays log 13.34 |
17:07:42 | preglow | sure, lemme know when you've read it |
17:07:45 | * | preglow goes washing up |
17:11:02 | | Nick jborn_ is now known as JoeBorn (n=jborn@dsl017-022-247.chi1.dsl.speakeasy.net) |
17:18:10 | Slasheri | preglow: hehe, there is no 1334 on my log :) now i have to guess the time zone.. searching :D |
17:19:02 | Slasheri | oh well, it was 1434 ;) |
17:20:07 | preglow | 13.34.07 # <preglow> anyone got any clever ideas on how to handle audio modifications without heaps of latency on rockbox? |
17:20:17 | Slasheri | preglow: yes, that is problematic.. |
17:20:19 | preglow | ahh, i meant the rockbox log, heh |
17:20:59 | Slasheri | even if we could access directly the pcm buffer, we cannot "undo" the crossfading without re-decoding |
17:21:02 | Slasheri | hehe |
17:21:06 | preglow | Slasheri: we _need_ to fix that, imho, in no way can i (or most users, i guess) accept a five second latency in their eq adjustments |
17:21:31 | Slasheri | or undo any other changes.. |
17:21:43 | Slasheri | that needs decoding the affected part again |
17:21:47 | preglow | oh yes |
17:21:49 | | Join kurzhaarrocker [0] (n=none@dsl-084-061-026-212.arcor-ip.net) |
17:22:39 | preglow | easiest way of doing it is storing the buffer in full precision and doing the dsp part closer to actually sending the data to the dac |
17:22:41 | kurzhaarrocker | Strange. I can't find out to which of my email adresses the rockbox mailing list sends to. I don't find any of my personal mail adresses in the header. |
17:22:44 | preglow | but that wastes a lot of memory, of course |
17:22:45 | preglow | brb |
17:23:40 | Slasheri | preglow: hmm, that's true.. but yes, it doubles the memory consumption |
17:27:08 | kurzhaarrocker | found it |
17:27:10 | | Part kurzhaarrocker |
17:27:10 | | Join IanPM [0] (i=ianpm@ibluemyself.net) |
17:29:46 | * | rasher stares at ManualMainMenu |
17:30:03 | rasher | That's so harsh |
17:30:06 | IanPM | I don't suppose anyone knows any projects similar to Rockbox for the SonyHD5 do they |
17:30:52 | linuxstb | I don't know any projects similar to Rockbox. |
17:31:35 | linuxstb | All I know is Rockbox, ipodlinux, and then various projects which hack linux-based devices |
17:32:20 | preglow | Slasheri: we could also of course do all dsp on the 16 bit data, but that would break our idea of an internal format and might give precision problems |
17:33:44 | linuxstb | Is the current PCM buffer as small as it can be, or could we reduce it? |
17:34:41 | rasher | 19 pages left. |
17:34:56 | IanPM | Shame, the HD5 could use some work in the firmware department |
17:36:30 | | Quit Seedy (Read error: 110 (Connection timed out)) |
17:43:32 | | Join ze [0] (i=ze@ca-dstreet-cuda1-c6a-81.snbrca.adelphia.net) |
17:51:33 | preglow | linuxstb: can probably reduce it, but it's nice to have it largeish |
17:51:41 | preglow | to compensate for sudden load spikes |
17:53:24 | | Join noC|andY`fRa [0] (i=andy@dsl-084-058-096-083.arcor-ip.net) |
17:54:01 | linuxstb | preglow: I only asked because at the start of the iriver port, we set everything much larger than needed. |
17:54:08 | preglow | linuxstb: it's been reduced since then |
17:54:19 | linuxstb | I should pay more attention :) |
17:54:28 | preglow | can't follow everything |
17:55:01 | amiconn | rasher: Is the attachment problem solved now? |
17:55:23 | amiconn | Ah, apparently it is :) |
17:55:30 | rasher | amiconn: I believe so - the new TWiki version was handling attachments differently |
17:55:38 | * | amiconn is going to upload fresh voice files |
17:56:11 | preglow | amiconn: excellent |
17:56:34 | HCl | queen rocks |
17:57:15 | preglow | amiconn: can't fix stereo width and channel config stuff at the moment thanks to apps/firmware clash |
17:57:29 | preglow | amiconn: and btw, where do you actually set the 'custom' channel configuration? |
17:58:09 | preglow | Slasheri: oh, and yes, why are the DSP_* constants put in playback.h of all places? |
17:58:09 | amiconn | (1) Hmm, what clash? (2) "Custom" uses the "Stereo width" percentage |
17:58:40 | Moos | amiconn: what's about the recording bit-shift problem, any news? |
17:58:44 | preglow | amiconn: stereo width and co are placed in sound.c, and i can't call dsp code from firmware code |
17:58:59 | amiconn | All other modes ignore that, and use their own config (mono = 0%, stereo = 100%, karaoke ~ infinity) |
17:59:48 | | Nick Asku_ is now known as Asku (n=aksu@adsl-39.180-DynIP.ssp.fi) |
18:00 |
18:02:47 | amiconn | preglow: All channel configurations are handled in sound.c/set_channel_config() |
18:03:22 | amiconn | case SOUND_CHAN_CUSTOM: calculates the scaling factors for custom mode |
18:04:01 | amiconn | sound_set() calls this function in two cases |
18:04:23 | amiconn | The clash is in fact a difference in architecture |
18:04:47 | preglow | yep |
18:05:01 | amiconn | For hwcodec, stereo width is part of the hardware settings just like volume, bass etc |
18:05:13 | preglow | yes, indeed |
18:05:25 | amiconn | For swcodec it goes into an entirely different module |
18:05:30 | preglow | all the settings we've implemented for iriver so far have been hardware based |
18:05:33 | preglow | so no clashes |
18:05:38 | amiconn | Perhaps we should have a dsp_set() in apps/dsp.c |
18:06:12 | amiconn | ...and use that insetad of sound_set for "soft" settings |
18:07:27 | amiconn | In fact we could do so for all platforms, but that's a thing I'd like to discuss with Linus too |
18:07:58 | amiconn | After all, the stereo matrix settings of the mas are dsp settings, as is the pitch setting |
18:08:08 | Slasheri | preglow: ah, i think there is no real reason for that. They can be moved to dsp.h |
18:08:16 | preglow | Slasheri: ok, i'll try |
18:08:19 | amiconn | The mas is divided in 2 parts that are somewhat independent. |
18:08:20 | Slasheri | good :) |
18:08:43 | amiconn | (1) The audio codec (2) The dsp |
18:09:08 | preglow | amiconn: pitch change on mas isn't "gapless" ? |
18:09:19 | amiconn | Volume, balance, bass, treble, loudness, MDB are part of the dsp |
18:09:27 | amiconn | Err, part of the audio codec |
18:10:07 | amiconn | preglow: No, because the pitch shifting is done by "cheating" |
18:10:12 | preglow | amiconn: yeah, i saw |
18:10:18 | preglow | iriver pitch change will be seamless, at least |
18:10:21 | preglow | amiconn: how long is the gap? |
18:10:25 | amiconn | We tell the mas a different clock frequency than it really has |
18:10:45 | amiconn | When pithcing up, we're effectively overclocking the MAS dsp |
18:10:57 | bobTHC | but on the terratec who use the MAS too , the pitch feature work well |
18:11:15 | amiconn | The gap is a fraction of a second |
18:11:29 | amiconn | bobTHC: With or without gap? |
18:11:41 | bobTHC | without and without disto |
18:11:58 | preglow | bobTHC: well, yeah, but i'm certain they've got a proper pitch changing effect |
18:12:06 | bobTHC | for sure |
18:12:16 | preglow | remember that rockbox has to do it by cheating because it has no intended real pitch change function |
18:12:23 | *** | Saving seen data "./dancer.seen" |
18:12:48 | amiconn | bobTHC: Would be interesting to know how they do it |
18:12:49 | bobTHC | iirc we've got some info on the MAS programming ? |
18:13:50 | preglow | yes, but please don't remind us ;) |
18:13:57 | | Quit Maxime (Read error: 104 (Connection reset by peer)) |
18:14:28 | | Join Maxime [0] (n=flemmard@fbx.flemmard.net) |
18:15:16 | bobTHC | why amiconn ? |
18:15:57 | bobTHC | iirc it was a [IDC]dragon announce... |
18:17:04 | bobTHC | i found the thread => http://forums.rockbox.org/index.php?topic=587.msg2679#msg2679 |
18:17:43 | preglow | yes, it's true, but programming the mas is very hard |
18:17:54 | amiconn | This is about the pcm codec. I have that available |
18:18:12 | amiconn | It's not about general MAS programming info |
18:18:33 | | Join Seed [0] (n=ben@l192-117-115-168.broadband.actcom.net.il) |
18:18:40 | amiconn | The pcm codec is binary & accompanied by a datasheet similar to the standard MAS datasheet |
18:19:20 | bobTHC | so pcm wave playback is possible ? |
18:19:37 | amiconn | Yes, and recording |
18:19:43 | bobTHC | but what the deal with the bandwith ? |
18:20:13 | amiconn | Playback should be a no-brainer, as the serial bandwidth is 3MBit/s and it's fed via DMA |
18:20:32 | bobTHC | oki |
18:20:40 | amiconn | Recording is a different thing though. The interface is parallel, but we can't use DMA |
18:20:46 | | Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU) |
18:21:14 | amiconn | ...and have to use a routine that "mimicks" DMA as the MAS parallel port is designed to use DMA |
18:21:23 | bobTHC | ouch |
18:21:36 | amiconn | That's the one I'm struggling with... |
18:22:00 | bobTHC | :) |
18:23:14 | amiconn | In case the bitshift problem multiplies with the higher transfer speed needed for pcm recording, it might be impossible |
18:23:21 | | Join markun [0] (n=markun@bastards.student.ipv6.utwente.nl) |
18:24:10 | amiconn | For pcm playback/recording on archos the HD will probably be spinning all the time |
18:24:56 | bobTHC | and that can imply a quality limit... |
18:25:12 | amiconn | Why? |
18:25:34 | amiconn | (for internal mic it's obvious, but otherwise?) |
18:25:42 | | Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
18:27:45 | bobTHC | if when we record the bandwith requiered for 44Hz is higher than the parallel port |
18:28:19 | amiconn | Ah, you mean the parallel port bandwidth |
18:28:48 | amiconn | It _should_ be sufficient for 44.1/16/stereo _if_ we manage to solve the bitshifting problem |
18:29:41 | bobTHC | oki, nice |
18:31:43 | rasher | 6 wikipages left |
18:33:11 | rasher | all the worst ones, of course |
18:33:40 | preglow | well, well |
18:33:47 | preglow | what am i doing wrong, no codecs are working anymore, heh |
18:36:01 | | Join DrMoos [0] (i=DrMoos@m113.net81-66-159.noos.fr) |
18:36:37 | | Quit Moos (Read error: 104 (Connection reset by peer)) |
18:41:38 | | Join Gibbed [0] (i=rick@pool-71-108-13-161.lsanca.dsl-w.verizon.net) |
18:41:38 | | Quit Rick (Nick collision from services.) |
18:41:48 | | Nick Gibbed is now known as Rick (i=rick@pool-71-108-13-161.lsanca.dsl-w.verizon.net) |
18:52:37 | | Join tvelocity [0] (n=tony@ipa221.7.tellas.gr) |
18:54:14 | preglow | amiconn: no eta on release yet? |
18:54:16 | * | rasher considers declaring WpsGallery "lots" |
18:54:19 | rasher | "lost" |
18:54:36 | rasher | There have been 150 updates since the backup :-\ |
18:54:46 | preglow | rasher: i'd say let people fix that themselves |
18:55:02 | rasher | YEah |
18:55:16 | bobTHC | it's the easyest to refill imho |
18:55:29 | rasher | The ReleaseTodo is back - a version from 2005-09-06 |
18:56:32 | | Nick DrMoos is now known as Moos (i=DrMoos@m113.net81-66-159.noos.fr) |
18:57:11 | | Quit bobTHC ("Smoke Weed Every Day !") |
18:57:27 | | Quit Seed (Read error: 104 (Connection reset by peer)) |
18:59:27 | | Quit Rick (Read error: 110 (Connection timed out)) |
19:00 |
19:04:29 | rasher | So.. now only ManualMainMenu, WpsGallery, ReleaseTodo and TrackScreen are out of date |
19:04:38 | rasher | ManualMainMenu is a beast. |
19:04:56 | rasher | WpsGallery might as well be updated by people who put them there in the first place |
19:05:22 | rasher | ReleaseTodo needs to be checked and updated. Shouldn't be too hard. It's as up to date as the searchengines allow. |
19:05:27 | rasher | TrackScreen is just lost. |
19:05:35 | rasher | The update, that is. |
19:07:02 | | Quit IanPM ("leaving") |
19:15:04 | | Quit thegeek (Read error: 113 (No route to host)) |
19:15:57 | | Join thegeek [0] (n=thegeek@s057b.studby.ntnu.no) |
19:21:12 | | Quit rasher (Remote closed the connection) |
19:23:42 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
19:26:04 | | Join crash3m [0] (i=crash3m@unaffiliated/crash3m) |
19:32:26 | | Quit markun (Remote closed the connection) |
19:34:06 | | Join Mxm`Pas`Bien [0] (n=flemmard@fbx.flemmard.net) |
19:37:00 | | Join hshah [0] (i=hshah@ACCA9D96.ipt.aol.com) |
19:49:16 | | Quit hshah ("Leaving") |
19:49:16 | | Quit Maxime (Read error: 110 (Connection timed out)) |
19:52:37 | | Join Rick [0] (i=rick@pool-71-108-13-161.lsanca.dsl-w.verizon.net) |
20:00 |
20:05:58 | | Quit paugh ("Leaving") |
20:08:53 | | Join linuxstb_ [0] (n=5343d4aa@labb.contactor.se) |
20:09:05 | | Join Lear [0] (n=chatzill@h36n10c1o285.bredband.skanova.com) |
20:09:28 | preglow | Lear: yo, any reason for not thinking the ogg problem with the alloca is gone? |
20:09:44 | preglow | Lear: and why not use builtin_alloca for the sims as well? |
20:09:44 | | Nick Sucka is now known as Sucka`away (n=NNSCRIPT@host81-156-157-185.range81-156.btcentralplus.com) |
20:10:22 | | Quit dpassen1 () |
20:12:24 | *** | Saving seen data "./dancer.seen" |
20:13:05 | | Quit Mxm`Pas`Bien (Read error: 104 (Connection reset by peer)) |
20:13:22 | | Join Maxime [0] (n=flemmard@fbx.flemmard.net) |
20:17:51 | Lear | Well, I have only had one ogg causing crashes, so I fixed that problem... |
20:18:19 | Lear | And I tried using it in the simulator too, but I got link errors then, don't know why... |
20:18:52 | Lear | (Not exactly sure what you mean with the first question, I must say... :) ) |
20:18:56 | preglow | very strange, builtin_alloca is a compiler hint more than anything |
20:19:10 | preglow | it's not an actual function |
20:19:59 | preglow | you said in the post you thought you're not sure how complete the fix is |
20:20:06 | preglow | just wondering what makes you think it's not complete |
20:21:04 | preglow | we're probably going to need a better malloc some day :/ i don't think we'll ever get rid of them, so might as well do it properly |
20:28:53 | Lear | Ah, well, that's simple. After having tested the problem a bit, I came to think of the alloca thing (didn't like it when I first saw it), so I gave it a try, not knowing if it would help. |
20:29:31 | Lear | It did turn out to help, and at that point I wrote the post. Later on I actually tried it with debug prints in the simulator, to see the real behaviour. |
20:29:33 | preglow | i actually spotted that bug while away the last weekend |
20:29:36 | preglow | but you beat me to it, heh |
20:29:50 | preglow | the previous implementation was right out wrong |
20:29:58 | preglow | and the current sim implementation still is |
20:30:00 | Lear | And it was lots of small alloca()s from one place in Tremor. |
20:30:40 | | Join solexx_ [0] (n=jrschulz@d155158.adsl.hansenet.de) |
20:30:59 | Lear | Regarding builtin, aren't they all intrinsic (sp?) functions, i.e., stuff that generates code inline? Happens on target at least. |
20:31:06 | preglow | they are |
20:31:09 | preglow | so do alloca |
20:31:13 | | Quit Sucka`away ("a bird in the bush is worth two in your house") |
20:31:24 | preglow | it just keeps track of how much to subtract from the stack pointer when the function exits |
20:31:38 | Lear | Anyway, didn't look closely at the sim problem; audio playback is a bit "shaky" there anyway... |
20:31:39 | preglow | and that's how the automatic deallocation happens |
20:31:45 | preglow | probably, never tried it |
20:32:15 | preglow | but alloca for gcc is always #defined to __builtin_alloca via alloca.h |
20:32:16 | Lear | Yeah, I know. There's some alignment stuff too. Nothing complicated or magic though. :) |
20:32:33 | Lear | Yes, I was a bit surprised when it didn't work... |
20:33:34 | | Join rasher [0] (n=jonas@83.72.66.7.ip.tele2adsl.dk) |
20:33:53 | preglow | btw, do you know if the "rumours" of tremor on rockbox being more efficient than in the iriver fw is true? |
20:34:41 | preglow | if so, we should really beat them into the ground with the additional 16kb of iram we don't use yet |
20:36:37 | Lear | I haven't read those rumors, and they are difficult to substantiate. Battery runtime, which is pretty much the only way to measure it (short of a BDM or something), shows more differences than CPU load... |
20:36:54 | Lear | But you need to do something useful with those 16 kb... |
20:37:00 | preglow | oh, indeed |
20:37:06 | preglow | putting the entire floor decode in iram, for example :P |
20:37:36 | Lear | What I'd like to see is someone try out that "MDCT via FFT" thing, to see if it is faster on the Coldfire. |
20:37:52 | amiconn | We're compiling with -ffreestanding which implies -fno-builtin |
20:37:53 | Lear | Maybe the FAAD code can be used right away? :) |
20:38:11 | preglow | amiconn: for both sims and targets? |
20:38:20 | Lear | amiconn: and that affects __builtin_alloc in what way? |
20:38:26 | | Join Mxm`Pas`Bien [0] (n=flemmard@fbx.flemmard.net) |
20:39:01 | preglow | in no way |
20:39:07 | Lear | floor decode, the code you mean? |
20:39:08 | preglow | as long as you spell it out to gcc |
20:39:11 | preglow | Lear: yes |
20:39:14 | | Quit Maxime (Read error: 104 (Connection reset by peer)) |
20:39:14 | amiconn | Lear: __builtin_alloca() should be available under this name, but not as alloca() |
20:39:30 | amiconn | ...unless you explicitly #define alloca |
20:40:17 | preglow | Lear: i know code cache, etc etc, but it usually actually does make a difference |
20:40:27 | preglow | Lear: and there's not much data left to be put in iram |
20:41:07 | Lear | I've noticed too, but is the floor decode that large part of the decode? Don't remember seeing it in the quick profiling I did (not on target, true)... |
20:42:01 | Lear | Window lookups for more than 256 and 2048 can actually be useful. With different sampling frequencies, and with much compression, window sizes can range from 256 to 4096 with the current encoder. |
20:42:06 | preglow | i believe it is, that's where the entire floor construction and dot product is done |
20:42:10 | preglow | not 100% sure, of course |
20:42:13 | preglow | besides |
20:42:22 | preglow | there is some data malloced here and there that we can put in iram |
20:42:27 | preglow | a lot of constant size mallocs |
20:43:39 | Lear | Btw, I think it was in vorbis_lsp_to_curve that did the alloca()s causing problems, so it is only used on low quality oggs or something. |
20:44:31 | Lear | And that function has been written in arm asm as well, so it might benefit from some attention... |
20:45:00 | preglow | ehh |
20:45:03 | preglow | that's a floor0 function |
20:45:23 | preglow | in which case it isn't just a low quality ogg problem, it's a very-old-encoder problem |
20:45:49 | Lear | Another thing: the alloca fix has one negative side effect: during decode setup, up to ~3.5 kB stack can be used by a certain function... |
20:46:06 | | Quit solexx (Read error: 110 (Connection timed out)) |
20:46:15 | | Quit Moos ("Parti") |
20:46:21 | preglow | Lear: yes, but it's still no way near libmad stack usage, no? |
20:46:29 | preglow | Lear: in which case i don't see anything to worry about ;) |
20:46:38 | Lear | Don't ask me. :) |
20:47:28 | Lear | No, the problem file I used to locate the problem (twit21) is encoded by libvorbis 1.1.0, which isn't particularly old... |
20:47:29 | preglow | libmad has 90% usage |
20:47:35 | preglow | hmm, well |
20:47:43 | preglow | floor type 0 is only used by really old encoders, afaik |
20:48:01 | preglow | that's the bark scale thing |
20:48:10 | | Join Febs [0] (n=upirc@70.5.215.111) |
20:49:53 | * | Febs found a way to access irc using his Treo smartphone. |
20:50:07 | Lear | wait a minute, it might have been _01inverse too. Don't quite remember... :) |
20:50:18 | | Quit Rick ("I… don't need to be here.") |
20:50:27 | Febs | Websense be damned! |
20:51:14 | Febs | rasher, you were looking for me earler? |
20:51:20 | preglow | haha |
20:52:48 | | Join Rick [0] (i=rick@pool-71-108-13-161.lsanca.dsl-w.verizon.net) |
20:53:23 | | Quit rasher ("Ex-Chat") |
20:53:54 | | Join rasher [0] (n=jonas@83.72.66.7.ip.tele2adsl.dk) |
20:54:37 | rasher | Febs: It was something to do wiith WikiManual.. I figured it out - hadn't seen the mail at that point |
20:55:52 | Febs | ok. I know that ManualMainMenu is going to be a nightmare ... I saw your earlier comment on that. |
20:56:29 | Lear | That MainMenu thing should be split into several pages, IMHO... |
20:56:31 | rasher | Yeah. It's pretty much the only one left |
20:56:45 | Lear | Bit of a pain to edit something that large... |
20:57:07 | Febs | lear, yes, I agree. |
20:58:08 | Febs | Originally I had ALL of the menus in one page, but that grew too big so I split it into chapters. |
20:58:40 | Febs | Menu menu is big enough now to require subchapters. |
20:58:41 | preglow | i wish monty had used whitespace when he wrote tremor |
20:58:47 | preglow | i hate reading source code with no whitespace |
20:58:58 | rasher | reindent it? |
20:59:30 | preglow | well, we should avoid modifying codecs |
21:00 |
21:00:00 | rasher | oh right, I forgot that |
21:00:32 | Febs | rather than simply restoring the previous ManualMainMenu page, I will take this opportunity to refine it. |
21:01:26 | preglow | i think i'll go play libflac on tremor as well |
21:01:40 | preglow | throw some calloced shit into static variables instead |
21:01:54 | * | preglow croons for a wav writer |
21:03:02 | preglow | Lear: i wonder how much we should strive to support floor0 files |
21:03:10 | preglow | no oggenc has made them since god knows when |
21:03:13 | preglow | and we waste good iram there |
21:03:17 | goa | is or will there be any kind of "database browsing", such es listing by artists or genres? |
21:03:28 | preglow | goa: there is |
21:04:02 | goa | preglow: ah sorry, the site seems to be online again, so i'll rtfm ;) |
21:04:08 | preglow | Lear: ignore me, no idata in floor0 :> |
21:04:17 | preglow | goa: do that |
21:04:36 | goa | yeah, sorry. |
21:05:25 | preglow | no worries |
21:05:33 | preglow | i'm not being harsh ;) |
21:05:54 | goa | ok =) |
21:09:36 | goa | ehrm, just while I fly over it, there is "crossfading" under "Features we will not implement" −− for that, it works pretty good ;p |
21:09:58 | rasher | Where are you reading this? Url? |
21:10:07 | goa | http://www.rockbox.org/twiki/pub/Main/RockboxManual/rockbox-manual-2.4.pdf |
21:10:17 | goa | page 87 |
21:10:19 | rasher | Ah, that's outdated |
21:10:29 | goa | mh :/ |
21:10:35 | rasher | http://www.rockbox.org/twiki/bin/view/Main/NoDo |
21:10:41 | goa | thanks. |
21:12:38 | goa | erm, do i have a cache problem? the same sentence is there ;/ |
21:12:54 | goa | oh sorry, missed the "Archos line of players" |
21:13:10 | rasher | Yup, that page has been split for that exact reason |
21:16:54 | | Join hicks [0] (n=hicks@zeus.mups.co.uk) |
21:24:36 | | Quit linuxstb_ ("CGI:IRC (Ping timeout)") |
21:27:06 | | Join Dma-Sc [0] (i=Dma-Sc@ALagny-151-1-79-49.w81-249.abo.wanadoo.fr) |
21:29:36 | goa | preglow: mh ok, so it seems to be this one http://www.rockbox.org/twiki/bin/view/Main/UseDisplayName there is no support for ape2 tags (yet), right? |
21:30:06 | rasher | Correct |
21:30:07 | Dma-Sc | the devkit downloadable in the wiki is really not corresponding to the instructions, as someone pointed in the forum |
21:32:12 | preglow | well |
21:32:15 | preglow | wavpack supports ape2 |
21:32:27 | preglow | but i guess the db doesn't |
21:32:30 | Febs | wiki question: is there any equivalent to the html COLSPAN function? |
21:32:31 | preglow | a shame, 'tis |
21:32:55 | Febs | I want a 3 column table ... |
21:32:55 | preglow | what would be great would be the db gen being written in c and using the rockbox metadata parser |
21:33:09 | rasher | Febs: horizontal merging? |
21:33:17 | rasher | |foo|| |
21:33:20 | rasher | |bar|baz| |
21:33:23 | Febs | where columns B and C are combined in some instances |
21:33:31 | rasher | that'll make foo span two cells |
21:33:46 | rasher | (no space between ||) |
21:34:12 | | Join linuxstb_ [0] (n=5343d4aa@labb.contactor.se) |
21:34:27 | Dma-Sc | well i was wrong about the devkit, it's correct, it's just two persons who can't read (me and the forum guy)... ;) |
21:34:43 | Febs | got it. It was the 'no space' that was throwing me off. |
21:34:44 | Febs | thx. |
21:34:48 | goa | preglow: yup, i only have wavpack files here, that's why i asked ;) |
21:35:13 | preglow | goa: well, rockbox supports ape2 in wavpack files, but the db generator doesn't, afaik |
21:35:45 | goa | preglow: mh, is there a donate button somewhere? =) |
21:36:07 | rasher | goa: rockbox.org under the menu |
21:36:10 | preglow | goa: sure, on the front page, downmost left |
21:36:28 | goa | omg, i'm blind.. |
21:36:53 | preglow | goa: but don't expect a donation to give you apev2 support in the db gen, only sucking up to HCl will get you that, hehe |
21:37:44 | | Nick NibbIer is now known as nibbler (n=sven@port-212-202-77-14.dynamic.qsc.de) |
21:42:05 | | Quit Febs ("Leaving") |
21:42:50 | | Join Seed [0] (i=ben@l192-117-115-168.broadband.actcom.net.il) |
21:43:04 | goa | preglow: i'll just wait until it's done, it's the same with all opensource projects ;) but that doesn't mean that they could not use some support :) and if i cannot help with things i have, (hosting, server or bandwidth) then i'll drop a few EURs to paypal.. |
21:45:11 | preglow | i don't think you'll see any complaints on receiving a donation, no |
21:47:16 | preglow | by god, is people unable to unsubscribe themselves these days? |
21:48:08 | rasher | Yes, yes they are. |
21:51:44 | | Quit Seed ("cu, Andre") |
21:52:59 | | Join Seed [0] (i=ben@l192-117-115-168.broadband.actcom.net.il) |
21:56:44 | goa | done, 50$, not much, but maybe a small motivation to continue this project.. |
21:57:27 | | Join [IDC]Dragon [0] (n=idc-drag@p54839C08.dip0.t-ipconnect.de) |
21:57:55 | Zagor | goa: thanks. $50 is lots, and very appreciated. |
22:00 |
22:04:56 | [IDC]Dragon | amiconn, have you located the recording loop in the archos s/w? |
22:05:02 | preglow | goa: 50 is much for a donation, you're an angel |
22:05:42 | [IDC]Dragon | is that for backup tapes? |
22:05:46 | preglow | :P |
22:06:02 | * | [IDC]Dragon tiptoes sideways, to avoud the worst flames |
22:12:25 | *** | Saving seen data "./dancer.seen" |
22:18:18 | | Quit rasher (Remote closed the connection) |
22:37:54 | | Join Moos [0] (i=DrMoos@m113.net81-66-159.noos.fr) |
22:40:04 | | Quit linuxstb_ ("CGI:IRC") |
22:45:02 | | Quit Lear ("Chatzilla 0.9.68.5.1 [Firefox 1.4/undefined]") |
22:45:14 | | Quit Seed (Nick collision from services.) |
22:47:31 | | Join hshah [0] (n=hshah@ACD6AFE3.ipt.aol.com) |
22:47:45 | Dma-Sc | simulator rule for designing wps :) |
22:47:59 | hshah | ur the one who posted in my thread :p |
22:48:03 | hshah | read my reply... |
22:52:23 | | Join stripwax [0] (n=stripwax@i-83-67-214-206.freedom2surf.net) |
22:52:27 | stripwax | hey |
22:53:42 | Dma-Sc | hshah, eheh yeah i replyed :) |
22:58:40 | hshah | cool thanks Dma-Sc |
23:00 |
23:00:47 | Dma-Sc | pretty nice that this tutorial/devkit exists, it saves time :) |
23:01:44 | hshah | took me a while to write it - but decided to do so coz i was stuck in the same position as many others |
23:03:08 | | Quit noC|andY`fRa (Read error: 104 (Connection reset by peer)) |
23:05:15 | | Join burningrave1011 [0] (i=burningr@67.110.59.70.ptr.us.xo.net) |
23:05:21 | | Part burningrave1011 |
23:05:54 | | Join rasher [0] (n=jonas@62.79.64.148.adsl.hs.tiscali.dk) |
23:07:25 | Dma-Sc | hshah : i can imagine that in packaging a clean devkit is quite apinful |
23:07:30 | Dma-Sc | in > and |
23:07:58 | hshah | rasher- how is the wiki restore coming along |
23:08:04 | hshah | packaging devkit? |
23:08:17 | rasher | Pretty much done, I'd say |
23:08:47 | Dma-Sc | hshash : yeah the devkit package .exe i mean |
23:10:23 | | Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
23:11:22 | * | rasher positions himself squarely on the fence in the neuros talk |
23:12:35 | fuzzie | good work. |
23:12:55 | rasher | Thanks. |
23:20:22 | | Join Dan [0] (i=Bollocks@tredwell.plus.com) |
23:26:39 | | Quit hshah ("Leaving") |
23:30:07 | | Quit edx (Read error: 110 (Connection timed out)) |
23:47:12 | | Quit DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
23:53:59 | | Join webguest59 [0] (n=51429f71@labb.contactor.se) |
23:54:09 | webguest59 | Hola muchachos |
23:54:19 | rasher | Well hello there |
23:54:41 | webguest59 | o scuse |
23:55:32 | webguest59 | what is the status of release please? |
23:55:53 | rasher | Waiting for recording tests/fixes |
23:56:03 | webguest59 | 1 month is so long :) |
23:56:13 | webguest59 | what is wrong with it? |
23:56:25 | rasher | Recordings break after a few hours |
23:56:47 | webguest59 | planed to fix it, or release with? |
23:57:02 | rasher | Hard to tell - the ball is amiconn's |
23:57:14 | webguest59 | ah ok |
23:57:28 | rasher | But he's not around much this week |
23:57:33 | webguest59 | he is alone in this bug? |
23:57:53 | rasher | Pretty much. |
23:58:03 | webguest59 | alone working on it, want to tell |