--- Log for 20.09.105 Server: herbert.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 19 days and 18 hours ago 00.04.11 # indeed 00.05.42 Quit noC|andY`fRa (Read error: 104 (Connection reset by peer)) 00.07.58 # Hrm, the tables are not quite what they used to 00.08.09 # how so? 00.08.20 # They're much darker now 00.08.35 # Hm.. maybe 00.08.45 # Maybe it's just because of missing styles 00.08.47 # nevermind me 00.08.49 # darker? they are transparent now. 00.09.01 # or do you mean the header row? 00.09.09 # Sorry, I meant the borders 00.09.15 # ah 00.09.20 # 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 # right, the borders are slightly thicker now. 00.12.07 *** Saving seen data "./dancer.seen" 00.28.25 # looks all good to me 00.29.00 # solved the registration problem? 00.29.59 # 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 # when's the award show? 00.45.03 # drammensveien 55, oslo, next weeken! 00.45.07 # weekend, even 00.45.34 # i'm actually going to denmark next weekend, we'll just do the awards ceremony there 00.46.42 # Heh 00.46.51 Join edx [0] (i=edx@p54A8677C.dip.t-dialin.net) 00.50.42 Quit markun () 00.51.39 # registration works now 00.52.46 # 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 # you didn't lose any of the mailing list info? 01.00.36 # Zagor: how about the attachment weirdness? 01.01.41 # 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 # Erp.. that's not good 01.02.15 # I could upload something to a test-page? 01.02.24 # please do 01.03.43 # so now the ReleaseTodo page has an attachment 01.03.57 # which.. doens't show up either 01.04.00 # crikey 01.04.56 # not releasetodo 01.04.57 # hang on 01.05.09 # ThingsTodo 01.05.14 # http://www.rockbox.org/twiki/bin/attach/Main/ThingsTodo still nothing though 01.06.03 # very strange. i'll see what the code does. 01.10.14 # 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 # It was for the apache-user. Still curious though 01.11.00 # why the mailing list would be deletable by www-data is weird 01.11.01 # lots of stuff was group-writable by this user, including the mailing list configs 01.11.13 # ah 01.11.21 # I see 01.11.55 # 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 # oh? 01.17.33 # isn't database stuff usually owned by dbuser:dbuser, btw? 01.17.48 # or doesn't twiki store stuff in a db exclusively? 01.18.03 # no, each topic is an rcs file 01.18.19 # ahhh 01.18.31 # lookie, attachments! 01.18.41 # and there was much rejoicing 01.18.54 # there was indeed a change in the handling in this version 01.20.47 # excellent 01.21.40 Quit DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 01.23.57 Quit ashridah ("Leaving") 01.25.54 # Is the following line of C correct? 01.25.55 # if (inl(0x2000) == "gfCS") { ... 01.26.26 # no 01.27.04 # Didn't think so. 01.27.52 # 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 # linuxstb: was that from ipodlinux code? 01.31.31 # I'm guessing yes.. 01.31.39 # 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 # well 01.32.04 # you'd need some pretty nifty magic for that code to work 01.32.12 # since it compares two pointers... 01.33.34 # I assumed inl() returned a long 01.33.49 # ...which only makes it more weird 01.33.49 # Me too. 01.35.53 # well, you still compare something to an arbitrary pointer 01.35.58 # which is pretty weird 01.36.33 # yes 01.37.18 # Checking the IRC logs, someone on #ipodlinux spotted it as well. But it hasn't been fixed yet. 01.37.30 # i wonder what the hell that line is supposed to do 01.37.47 # whoever wrote it had to be seriously fscked up on something 01.37.52 # It looks like completely black magic to me 01.38.06 # rasher: That's ipodlinux :) 01.38.31 # likely address 0x2000 contains the longword equivalent of ascii "gfCS" on that particular target 01.38.46 # Zagor: Yes, I think so. 01.39.01 # It just seems so weird 01.39.07 # inl is just a macro that reads from memory. 01.39.08 # and... stupid... 01.39.10 # and not even a comment.. 01.39.32 # committing code without even trying to compile it is kinda... icky too :-) 01.39.36 # well 01.39.39 # it will compile 01.39.39 # /* DANGER, HERE BE MAGIC! */ 01.39.41 Quit Moos (Read error: 110 (Connection timed out)) 01.39.42 # no problem, perhaps a type error 01.39.50 # warning, at best 01.39.59 Quit xen` (Read error: 110 (Connection timed out)) 01.40.13 # Yes, gcc gives the expected "tools.c:39: warning: comparison between pointer and integer" 01.40.34 # but hell 01.40.41 # people are so intent on ignoring warnings, it's no surprise 01.40.59 # fixing a warning with a #pragma is accepted practice with a lot of people :/ 01.46.46 # Zagor: Now I'm locked out :-X 01.47.05 # hang on.. 01.47.33 # now? 01.47.39 # I'm in! 01.47.50 # slight mistake :-) 01.54.19 # * linuxstb finally has some iPod success. 01.55.00 # elaborate :> 01.55.41 # I simply got the ipodlinux bootloader to run the Apple firmware. 01.56.39 # I'm just trying to work out exactly how much of my ipod ipodlinux supports. 02.11.30 # Just start porting rockbox already 02.11.52 # We're WAITING 02.12.09 *** Saving seen data "./dancer.seen" 02.14.08 # Patience. Maybe I should have bought myself an ipod that ipodlinux actually works on. 02.14.45 # hrmph 02.15.04 # should we put all the audio modifier stuff in the dsp layer or the pcmbuf layer of rockbox? 02.15.26 # 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 # i'm off to bed. good night guys. 02.20.39 # night 02.22.06 Quit tvelocity ("Leaving") 02.24.13 # 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 # Slasheri: please come back to me on this if you read ;) 02.25.10 # linuxstb: there's your cue 02.25.59 # 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 # I just saw why running Linux on an ipod is silly. 02.27.52 # "video playing has part of it in the kernel for various reasons" 02.28.02 # that's so wrong 02.28.42 # :/ 02.28.45 # well, gotta bed 02.28.46 # later 02.28.53 Quit preglow ("feaches") 02.43.35 Join Strath [0] (n=mike@dpc674681214.direcpc.com) 02.45.25 Quit dpassen () 03.09.17 # rasher, are you around? 03.09.34 # barely, but yeah 03.10.12 # What needs to be done to restore the wiki pages that you've cached? 03.10.32 # Does all formatting etc. need to be reapplied? 03.10.35 # Compare the current version to the cached html version, update what's changed in between 03.10.46 # this pretty much means "write any changes in wiki syntax" 03.10.52 # it's not a fun job.. 03.11.02 # No, I imagine not. 03.11.18 # I was afraid that's what you would say. 03.11.25 # Some are easier than others of course 03.11.31 # some have just had a line added/removed 03.12.46 # I'm specifically looking right now at this page: http://rasher.dk/rockbox/WikiRescue/ManualRockboxInstall-r1.10%20-%2008-31.html 03.13.12 # I take it that I have to reapply all of the wiki syntax for hyperlinks, tables, headings, etc.? 03.13.30 # Ah yes, you do indeed 03.13.59 # Rewrite from scratch :-\ 03.14.13 # Well, it could be worse. At least the text is preserved. 03.15.24 # Yes. It'll just take some time 03.16.55 # OK. I'll work on restoring some of the documentation pages that I wrote. 03.16.57 # Just prod me if you fix any pages, and I'll remove them from the list 03.17.01 # 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.55 Join DarkShadow [0] (n=4360fb3a@labb.contactor.se) 04.01.15 # Hey. 04.05.46 Join QT [0] (i=as@madwifi/users/area51) 04.06.40 # Hey. 04.07.29 # rasher, ManualRockboxInstall has been restored. 04.08.16 # Noted. 04.12.12 *** Saving seen data "./dancer.seen" 04.12.34 # 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.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.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.25.17 # morning :) 07.27.58 # rasher r u here ? 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 # morning, B4gder 08.12.27 # morning 08.12.40 # wiki is up, afaics 08.13.57 # i'm waiting for rasher to tell me which pages are already changed with last ones 08.14.29 # sounds like a fair approach 08.15.29 # * B4gder works on manually unsubscribing people 08.22.01 # people really can't read... 08.23.59 # LinusN what do u mean ? 08.24.38 # they can't follow directions, they try to send the "unsubscribe" messages to the list instead of the list-admin 08.28.28 # 410 subscribers now 08.40.06 # 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 # LinusN about the forensic analysis tool ... what did u use ? 08.43.27 Quit linuxstb_ (Client Quit) 08.44.46 # Bger: sleuthkit and foremost 08.45.08 # hm, i'll take a look at these, it's a nice to know thing ... 08.48.16 # i'll put up some links 08.50.33 # i suppose there are such tools for reiserfs ? 08.51.47 # i dunno 08.53.31 Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 09.05.48 # I hate stupid mailers 09.06.12 # "Your mail to the following recipients could not be delivered because they are not accepting mail from daniel@rockbox.org" 09.06.33 # from a user on the mailing list 09.06.47 # 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 # B4gder : u've just added more spam to your mail ..:) 09.12.36 # I don't care 09.12.36 # i see 09.12.36 # I get sooooooo much already 09.12.36 # btw: http://www.rockbox.org/twiki/bin/view/Main/RockboxOrgEmail 09.12.36 # LinusN what about pdf files ? 09.12.39 # coming 09.12.46 # good :) 09.22.33 Quit linuxstb (Read error: 110 (Connection timed out)) 09.27.41 # Mmm. It appears that the latest color ipods (like mine) have a PP5022 in them, not a PP5020. 09.28.50 # probably to support the lcd 09.32.37 # 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 # but ipodlinux doesn't support ipod photo, or i'm wrong ? 09.34.29 # Bger: It's "unsupported", but it works. 09.34.47 # heh 09.34.50 # most models seem "unsupported" but working 09.35.01 # Current status of ipodlinux is here: http://ipodlinux.org/Project_Status 09.35.01 # so, u've got your ipod 09.35.19 # Bger: Yes, but unfortunately it's one of the ones least supported by ipodlinux. 09.37.23 # 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 # now, what is the release waiting for really? 09.49.30 # its been 5 days since the latest archos related fix 09.57.19 # B4gder: amiconn has worked his ass off to find the recording bit-shift problem 09.57.49 # I know 09.58.04 # but how long will that take and do we really need it fixed before the release? 09.58.24 # isn't this a bug we've had like forever? 10.00.55 # yes 10.03.03 # sounds like extra important to fix it 10.03.04 # hi 10.03.10 # I say lets give amiconn the decision - release now or wait for him. 10.03.18 # yes 10.03.25 # recovered pdf files online as well 10.06.12 # hm, most of them must have been in the backup 10.06.36 # LinusN: What about other filetypes - e.g. .zip or .exe (assuming there were any). 10.07.12 # coming... 10.07.49 # talk about doing rubbish, or is it making something out of rubbish? ;-) 10.12.06 # bmp images up 10.12.17 *** Saving seen data "./dancer.seen" 10.12.31 # the recover tool must have problems with monocrome bitmaps 10.12.43 # I must go look for my cube gifs 10.13.17 # they are there 10.13.23 # they are? 10.13.39 # they're not on the gif page 10.13.40 # hmm, no :-( 10.14.53 # I think I still have them around 10.22.02 # 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 # hi 10.39.14 Join amiconn_ [0] (n=jens@p54BD42AD.dip.t-dialin.net) 10.43.00 Quit linuxstb_ ("Leaving") 10.57.23 # 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.01.35 # i went through the zips yesterday, renaming some to more useful names 11.01.59 # gifs and pngs too 11.02.31 # saw that 11.04.24 # Zagor: http://www.rockbox.org/twiki/bin/view/Main/WikiRestore 11.05.07 # yeah, found it 11.05.21 # did you move the png's? 11.05.31 # i didn't see any renamed png's 11.06.01 # maybe I only looked at them 11.07.41 # nice work on the pdfs. which tool did you use to snapshot the first page? 11.10.17 # imagemagick, of course 11.10.32 # wonderful tool 11.10.53 # aha. I didn't know it reads pdf too. 11.11.08 # convert xxx.pdf[0] -thumbnail 256x256 thumb_xxx.png 11.11.28 # i dodn't know it either, i just tried and it worked :-) 11.11.29 # 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 # + 100 Mbit/s connection 11.11.40 # it uses ghostscript for the pdf parsing 11.11.43 # argh, weird enter.. 11.11.56 # Slasheri: thanks, but no thanks 11.11.59 # ok 11.12.09 # we will make our own backup work 11.12.21 # and we only have a 2mbit/s connection 11.12.46 # shared with a lot of other sites 11.28.09 # gee. 11.28.18 # i don't trust the output of my perl converter script at all. 11.28.25 # who's good at perl? 11.30.22 # what's the problem? 11.31.53 # i wish i knew, heh. 11.32.02 # ftp://titania.student.utwente.nl/rtd1tortd2.pl 11.32.17 # its supposed to upgrade an runtime database v1 to runtime database v2 11.33.17 # maybe its just cause i forgot to close... 11.33.54 # or not 11.35.17 # forgetting to close was just one bug 11.36.52 # why add the "type" in the runtimedb? 11.37.05 # to support empty hashes, and filehash upgrades 11.37.28 # ? 11.37.36 # why is that related to perl/java? 11.38.04 # 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 # they should 11.38.42 # crc32 on 32K data should be the same 11.39.45 # what happens when we support the C coded version? 11.39.50 # the java version is attempting to be smart by skipping the id3 tag in mp3 files 11.39.54 # or if someone else decides to write one? 11.40.07 # HCl: and so does the perl version 11.40.18 # they do not produce the same results though. 11.40.32 # because the backends differ in quality of figuring out the id3 tag. 11.40.57 # i don't really see why they should be the same anyways. 11.41.11 # because you lock the user into a single db 11.41.16 # db tool 11.41.18 # forever 11.41.38 # why? 11.41.57 # what's the hash for? 11.42.03 # i don't see how we're doing that, at least, not with the hashtype upgrade. 11.42.06 # if the hash can differ, then what's the point? 11.42.21 # right, you need to run a conversion tool if you decide to build a new db 11.42.24 # thats one of the reasons why the hashtype field is getting added. 11.42.36 # then what type do I use when I write my new db tool? 11.42.47 # depends on how compatible it is with the rest. 11.43.05 # if its 100% compatible with say, perl, then the perl type. 11.43.08 # I say it is the wrong way out of this problem 11.43.48 # then propose a better one :) 11.43.57 # while at the same time solving the 0 crc problem 11.43.59 # sure - make them produce the same crc 11.44.06 # make the two tools produce the same hash 11.44.10 # the 0 crc is not depending on what version you use 11.44.14 # and exactly how do you propose to do that :) 11.44.19 # HCl: debugging? 11.44.21 # and exactly how do you propose future hash upgrades? :) 11.44.28 # uh? 11.44.37 # you mean when you change hash algo? 11.44.38 # in the future, we'll want to hash on the music data 11.44.41 # yes. 11.44.56 # what do we hash now? 11.45.03 # then you change db version 11.45.04 # the first 32kb, including id3 tags. 11.45.16 # and then destroy everyone's runtime database? 11.45.18 # i'd think not. 11.45.20 Join ashridah [0] (i=ashridah@220-253-120-220.VIC.netspace.net.au) 11.45.26 # then how can the two tools produce different hashes? 11.45.29 # no, and convert it to the new 11.46.04 # the perl version already checksums the audio data 11.46.06 # well, be my guest in either altering the perl or the java version in producing the equivalent of the other 11.46.12 # in the meanwhile 11.46.19 # i'll just use my own approach on my local tree. 11.46.29 # HCl: how cooperative 11.46.40 # sorry, but i'm not going to fix the java or perl version 11.46.43 # into generating the same hash. 11.46.50 # because i hate perl 11.46.56 # and the java one relies on a backend 11.47.03 # and though its completely open source with the source available 11.47.05 # so you want to bury the bugs by creating an additional tool layer? 11.47.12 # i am not going to figure out how it works, black box principle and such. 11.47.40 # sounds insane in my ears 11.47.42 # i personally think its better to support different type of hashes in the database itself 11.48.10 # possibly, but these should not be different types 11.48.14 # HCl: because you don't want to fix bugs? 11.48.18 # we have a defined way 11.48.21 # a defined format 11.48.29 # LinusN: because i want to support upgrading hash algorithms 11.48.29 # either we follow the format, or we don't 11.48.45 # you can change the java and perl version back to hashing the first 32k if you want 11.48.50 # they'd be equivalent then. 11.49.01 # but worse, obviously. 11.49.17 # then I say we dump the java way and we won't have this problem 11.49.34 # heh, good luck 11.49.47 # i'm not going to write a perl version to generate the database 11.49.59 # I already did 11.50.00 # and the java version is already superior to the perl version 11.50.06 # how? 11.50.15 # LinusN: its id3 reading backend is much better. 11.50.24 # the perl version generates crap pYi things 11.50.27 # in the database 11.50.33 # oh, a bug 11.50.34 # but we fix bugs in the perl version 11.50.39 # you refuse to do so in the java one 11.50.53 # you want to hide them instead 11.51.05 # the java version doesn't do that  11.51.05 # i 'm not going to fix bugs in code that other people wrote and isn't transparaent, no. 11.51.08 # i don't want to hide them. 11.51.21 # transparent? 11.51.24 # i want to upgrade the hashing algorithm to rely on music data 11.51.28 # that, yes. i'm lagging tons 11.51.40 # we already checksum music data 11.51.49 # but not consistently. 11.51.55 # then that's a bug 11.52.10 # the difference between perl and java 11.52.15 # is *not* the reason for the database update 11.52.31 # the reason is to support database hash upgrades 11.52.42 # easily 11.52.47 # and to support "no hash" instead of crc=0 11.52.50 # without having to bump the runtime database version all time 11.52.50 # yes. 11.53.44 # do we really need to do hash upgrades? 11.54.11 # I can see how we should support CRC == 0, but not why we'd need to change hash 11.54.27 # 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 # on top of that. 11.54.39 # since we need to support crc == 0 in the first place 11.54.47 # we have an extra field in the database anyways 11.54.50 # that we can use for hashtypes 11.55.07 # and thats simply 0 for no hash. 11.55.47 Join tvelocity [0] (n=tony@ipa221.7.tellas.gr) 11.55.56 # and when used, it is "crc32 on music" 11.56.06 # on 32K of music even 11.56.19 # we don't have that reliably implement. 11.56.21 # implemented 11.56.22 # ok, so the perl code has trouble finding the music content 11.56.23 # ? 11.56.27 # both the perl and the java versions 11.56.32 # have trouble finding the music content 11.56.36 # in certain files 11.56.44 # they may have bugs 11.56.52 # in some situations the perl version does better finding the music content 11.56.54 # but the perl version does as described 11.57.01 # and in some situations the java version does better at finding the music content 11.57.12 # and the perl version has id3 tag bugs 11.57.15 # that the java version doesn't have 11.57.35 # 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 # 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 # and there's not many tags in the middle 11.57.49 # think sounds like a reason to reconsider the crc idea 11.57.55 # this sounds 11.58.03 # we already discussed that zagor, the middle changes because the id3v2 tag data is at the front 11.58.05 # I like the 128K idea 11.58.10 # the same goes for 128k 11.58.12 # not reliable 11.58.17 # the amount of data in the front changes 11.58.22 # when id3v2 tags are changed 11.58.25 # ah yes 11.58.32 # middle 128k ? 11.58.38 # ok, we want to be "tag agnostic" 11.58.44 # and tool agnostic 11.58.46 # tagnostic 11.58.48 # right 11.59.03 # middle of frame data 11.59.05 # ? 11.59.05 # so we should fix the bugs then 11.59.20 Quit B4gder ("Lämnar") 12.00.16 # so both tools find the same music content 12.00.31 # i agree 12.00.55 # 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 # i've been wanting to get rid of the icky backend that does it for it now 12.01.20 # i also need samplelength and playlength though 12.01.36 # which is annoyingly tricky to get 12.02.13 # anyways 12.02.16 # i gotta go 12.02.17 # bbl 12.12.19 *** Saving seen data "./dancer.seen" 12.13.30 # gotta go too 12.13.33 Part LinusN 12.17.07 Join linuxstb [0] (n=d57b9aa9@labb.contactor.se) 12.18.29 # 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 # 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 # if reliable, then sure 12.24.15 # 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 # 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 # hi 12.59.17 # hi, amiconn 13.04.15 # How are your recording tests going? 13.05.25 # Not too well :/ 13.05.29 # gtg 13.05.32 # :( 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 # rasher ? 13.24.10 # Yup 13.24.32 # what pages are already updated? 13.24.37 # in the wiki 13.24.50 # Anything that isn't on my page 13.25.17 # Well, and a few more, I've not updated it since last night 13.29.55 # Check the page now 13.30.01 # http://rasher.dk/rockbox/WikiRescue/ 13.31.44 # ok 13.34.07 # anyone got any clever ideas on how to handle audio modifications without heaps of latency on rockbox? 13.37.31 # the changelog is BIG... 13.38.04 # I think we need a "digested" version for the average user 13.38.38 # preglow: What kinds of audio modifications are you talking about? 13.38.55 # Zagor: That's what I intended the releasenotes "what's new" section to be 13.38.59 # I should update these.. hang on 13.39.35 # linuxstb: eq, replaygain, stereo width, etc 13.39.57 # Just normal playback processing then? 13.40.34 # 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 # OK, I understand the problem. 13.41.16 # hi - i have a problem with recordings - the same as in bug [ 1152291 ] - has there been a bugfix for that? 13.41.36 # 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 # preglow: And the audio in the buffer could be from different tracks - so different resampling and replaygain would be needed. 13.42.29 # never thought about that 13.43.27 # rasher : how is the "checkmart" in wiki lang ? 13.43.33 # checkmark 13.43.40 # %Y% 13.45.27 # 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 # Is it common to change the DSP parameters during playback? Can't we just flush the buffer? 13.47.38 # well, that's what i thought about as well 13.47.55 # and that might fail for a slow codec 13.48.07 # especially if other stuff is going on, like loading 13.48.36 # changing a parameter sometimes requires a bit of extra prccessing as well, like for eqs 13.48.58 # 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 # Obviously if cross-fade was enabled, we would probably have to resample everything. 13.50.48 # 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 # So does the iriver spdif out support different samplerates? 13.52.49 # yeah, but not certain which of them are actually possible 13.53.32 # ChangeLog->General Section ok :) 13.53.40 # i know of 48000, 44100 and 32000 13.53.41 # might be more 13.55.11 # Bger: don't bother with it - I have a completely up to date version of it lying arount 13.55.24 # eh :( 13.55.39 # sorry I missed that 13.55.52 # re 13.56.09 # rasher : so, where to start from ? 13.56.28 # HowtoUpdateLangfile ? 13.56.56 # that's fine.. don't bother fiddling with the list at the bottom 13.57.03 # if the rest is correct, don't touch it 13.57.11 # I have a script that outputs the list at the bottom 13.57.45 # i didn't understand what do you want to say ... 13.57.47 # you're picking all the wrong ones! 13.58.14 # ok, give me topics to work on 13.58.34 # Well.. anything but ChangeLog and HowtoUpdateLangfile really 13.58.41 # hahaha :) 13.59.26 # ok, i must join in the lottery today for sure ... 13.59.31 # Heh 14.02.33 # oh well, i should talk to slasheri about this 14.03.56 # rasher IaudioX5Info ... i created nearly empty page, see your wiki rescue and u'll understand why... 14.05.09 # It *was* a nearly empty page except for a few image.. not much to do about that 14.05.18 # there's a typo though 14.05.48 # correct me :) 14.05.57 # No, in my rescue page I meant 14.06.10 # it said the cache I had was r1.2, but it was in fact 1.12 14.06.37 # yep 14.08.14 Join noC|andY`fRa [0] (i=andy@dsl-084-058-111-005.arcor-ip.net) 14.10.54 # rasher : what to do with the nonexisting links in text ? 14.11.09 # like %ATTACHURL%/decoded.gig 14.11.15 # s/gig/gif 14.11.58 # I've just put the filename in red 14.11.59 # so 14.12.09 # %RED%decoded.gif%ENDCOLOR% 14.12.20 *** Saving seen data "./dancer.seen" 14.12.21 # 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 # ok, clear 14.15.02 Part webguest83 14.15.17 # Which page? 14.16.43 # last edited :) 14.16.46 # 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 # rasher InsideMPIOHD200 done 14.27.19 # Ok 14.27.23 Join Moos [0] (i=DrMoos@m113.net81-66-159.noos.fr) 14.28.21 # IpodLinux done also 14.28.31 # Good day all! 14.29.33 # congratulations for the speed recovering Wiki 14.29.41 # Ugh, I am not looking forward to recreating the FileMenu and MainMenu wiki menu pages! 14.31.13 # 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 # 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 # hehe :) 14.38.17 # IriverBDM done 14.43.10 # 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 # 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 # Bger its a never ending story, never look back what you have done before ;-) 14.49.41 # :P 14.56.09 # rasher: i think they will, yes 14.56.34 # 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 # hi folks !! 14.58.07 # Bonjour bob 14.58.14 # :) 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 # linuxstb: darn, thats pretty sweet 15.18.11 # about flac/wavpack 15.20.20 # Is a 128-bit checksum going to cause you problems though? 15.21.50 # 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 # linuxstb: I investigated this.. on my entire collection, using the first 512 *bytes* was enough to avoid collisions 15.23.09 # Did that include the ID3 headers though? Which filetype(s) are in your collection? 15.23.17 # Of course, I don't have any WAV files beginning with perfect silence 15.23.38 # I'm not sure, I *think* I skipped id3 headers, but I'm not sure 15.23.44 # mix of mp3/ogg 15.23.49 # about 80/20 15.24.47 # I quite often edit MP2 radio recordings by splicing pre-encoded about 2 seconds of silent MP2 frames to the beginning. 15.25.05 # What the.. no PluginSolitaire in the wiki? 15.25.25 # This is about 83 frames at 576 bytes each - so more than 32K. 15.25.56 # I was advocating first+last X bytes, but that was ruled out because of increase disk-seeking 15.27.04 # i still think (file_size-tag_size)/2 + tag_size is a good position 15.32.43 # Zagor: I agree - the middle of the compressed data is a good place. Or simply just the middle of the file. 15.32.54 # It's also possible to pad the end of a track with silence. 15.33.04 # filesize/2 should be fine? 15.33.26 # I suppose we want to guarantee we are not including any metadata tags. 15.33.28 # it's not like the tag_size is significant compared to the filesize 15.33.53 # rasher: It shouldn't be, but I think some people do odd things with id3v2 tags 15.34.36 # Embedded music video! 15.40.34 # ahahahha 15.43.27 # determining the tag size will probably require even more seeking, though 15.43.55 # i agree with zagor, though eventually we might want a hash of the uncompressed pcm data 15.44.32 # i had collissions with the first 512 bytes 15.44.45 # as for the 128bit nature 15.44.51 # we'll just have to somehow scale it down 15.45.10 # either that or add an 128bit hash support to the database 15.45.54 # scaling down a hash is badness 15.46.07 # well 15.46.15 # it very much defeats their purpose 15.46.20 # i personally don't see too much problems with increasing the hash size in the database 15.46.26 # but i don't know about other people. 15.46.30 # that's what should be done 15.46.30 # definitely 15.46.46 # okay, so 128bit hash, as well as a field to say whether there is a hash or not? 15.47.02 # perhaps a hash/checksum type field, describing size and type :> 15.47.08 # where 0 means no hash 15.47.10 # thats what i suggested 15.47.16 # but some people were highly against it 15.47.20 # why? 15.47.21 # for reasons still fairly unknown to me. 15.47.28 # i dunno. 15.47.45 # rasher: IriverH3XXHardwareComponents done 15.47.45 # Bagder: ? 15.48.24 # 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 # Bger: ok 15.49.07 # well i'm glad my idea and implementation isn't totally rejected :p 15.49.12 # just need to upgrade the hash size 15.49.24 # 35 wikipages left. 15.52.23 # * Bger hopes that the backup system will be working very soon again 15.55.34 # 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 # rasher i hard can see any difference between IriverHardwareComponents rev 1.51 (in the wiki) and 1.52 (rescued) 15.58.04 # I'll see 15.58.04 # Bger: i'm doing manual backups now until things are in order again 15.58.13 # nice 15.58.16 Quit ender` (Read error: 110 (Connection timed out)) 15.59.09 # ah.. that's a tough one :-\ 16.00.31 Join muesli__ [0] (i=muesli_t@Bc0a8.b.pppool.de) 16.01.02 # maybe a typo ?:) 16.01.37 # No 16.01.41 # (F)P22AD-LVX245 is changed 16.02.25 # and that's it 16.02.33 # two places 16.02.42 # only one 16.02.49 # the other is %TOC% 16.03.03 # ah okay 16.03.05 # just renamed (F) to fairchild 16.03.11 # ok, i'll rename it 16.03.43 # i was checking tables, text ... 16.04.02 # ohm resistance ... :) 16.04.08 # hmm, i need to call apps/dsp.c code from firmware/sound.c, is that even possible? 16.05.13 # no 16.05.21 # then dsp.c needs to be in firmware/ 16.05.37 # Or sound.c needs to be in apps? 16.05.41 # perhaps 16.05.57 # but all the audio stuff for iriver is in apps now 16.07.13 # and to implement the 'stereo width' and 'channels' settings, i need to do work in dsp.c 16.07.27 # but the interface is in firmware/sound.c :/ 16.09.39 Quit muesli__ (Read error: 104 (Connection reset by peer)) 16.09.53 # Zagor: erp, locking is 60 minutes now.. could we lower it to 30 minutes? 16.10.04 # * rasher summons Febs 16.10.44 # IriverIfpPort done 16.10.59 # okay 16.11.03 # hah how does this sound :) 16.11.19 # 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 # "i just saw in the irc log that Rockbox already runs on iriver ifp" .... 16.11.57 # linuxstb: yes, i agree 16.12.01 # Similarly, some hardware will not need samplerate conversion. 16.12.08 # etc etc. 16.12.21 *** Saving seen data "./dancer.seen" 16.12.42 # i really think stuff like pcmbuf belongs in firmware as well, heh 16.12.46 # it's pretty lowlever 16.12.49 # IriverInstall is large :( 16.12.50 # lowlevel, even 16.17.58 # 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 # preglow: firmware/ sounds the right place to me. 16.21.49 # rasher: NonArchos done. found among recovered files. 16.21.58 # rasher : after ~ 10 min i'll go offline, so i WONT finish IriverInstall 16.22.52 # Bger: okay.. just save it locally and work on it when you get the time 16.22.55 # Zagor: noted 16.23.16 # rasher: i'll go home, and will continue to work on it tomorrow 16.23.35 # Okay 16.23.40 # only 26 left! 16.23.59 # good :) 16.24.10 # u're definitely quicker than me ;) 16.24.37 # I pick the easy targets, I think 16.25.24 Quit muesli- (Read error: 110 (Connection timed out)) 16.26.58 # this iriverinstall is written for idiots ... 16.28.20 # 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 # 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 # yes, that's usually the case 16.30.37 # i recovered a whole harddrive once, most of it was intermingled rubbish 16.30.44 # * preglow summons Slasheri 16.31.03 # rasher: what's the wiki code for the "idea's lamp" ? :) 16.31.21 # linuxstb: if i move dsp to firmware, the entire playback subsystem has to move as well, it seems 16.31.54 # preglow: might be a good time to step back and rethink the layers. 16.32.01 # now, why the flaming hell are the DSP_ constants in _playback.h_ 16.32.16 # the ones we have are very old and not designed for what we do today 16.32.38 # i still think they're ok 16.33.03 # 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 # sure 16.33.20 # i'm just giving things a try now 16.33.55 # 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 # Bger: hrm, %T% maybe (Tip) 16.35.57 # Bger: they're defined here: http://www.rockbox.org/twiki/bin/view/TWiki/TWikiPreferences 16.36.19 # 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 # ok, found it 16.36.30 # never mined 16.36.31 # mind 16.36.34 # i don't think i'm up too a big code restructuring, i'm very bad at that 16.36.35 # gotta go 16.36.45 # IriverInstall is ready up to "STEP 4" 16.36.51 # have you saved it? 16.36.54 # yes 16.36.58 # and it's unlocked 16.37.02 # I'll finish then 16.37.14 # as u wish 16.37.25 # if you don't do it, i'll finish it tomorrow 16.37.28 # bye 16.37.32 # bye 16.37.36 # thanks for the help 16.37.43 # heh 16.37.53 # thanks 2 u to 16.37.55 # o 16.38.26 # i don't think we must thank each other, everyone does this for all:) 16.38.29 # but indeed, playback.c has grown horribly 16.40.05 Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) 16.41.17 # Bger: still, hearing that ones work is appreciated from time to time is nice 17.01.07 # preglow: hi. Hmm, why would you ever want to move dsp part to firmware? 17.01.46 # even pcmbuf is not a firmware layer (which is used by dsp) 17.02.00 # Slasheri: because i need to interface with stuff in firmare/ 17.02.06 # like stereo width, channel settings 17.02.12 # 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 # Ah, hmm.. 17.02.24 # can you write an api to interface with that? 17.02.34 # i think dsp shouldn't need directly to access them 17.03.09 # 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 # but i think that's wrong 17.03.22 # hmm, yes.. 17.04.49 # the archos/iriver stuff really needs to be unified by some brave soul :/ 17.05.05 Quit ashridah ("Leaving") 17.05.52 # and there's another thing i'd like to ask your opinion about 17.06.04 # i think the mpeg.c needs to split into firmware and application layers.. 17.06.26 # but now some food -> 17.06.43 # todays log 13.34 17.07.42 # 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 # preglow: hehe, there is no 1334 on my log :) now i have to guess the time zone.. searching :D 17.19.02 # oh well, it was 1434 ;) 17.20.07 # 13.34.07 # anyone got any clever ideas on how to handle audio modifications without heaps of latency on rockbox? 17.20.17 # preglow: yes, that is problematic.. 17.20.19 # ahh, i meant the rockbox log, heh 17.20.59 # even if we could access directly the pcm buffer, we cannot "undo" the crossfading without re-decoding 17.21.02 # hehe 17.21.06 # 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 # or undo any other changes.. 17.21.43 # that needs decoding the affected part again 17.21.47 # oh yes 17.21.49 Join kurzhaarrocker [0] (n=none@dsl-084-061-026-212.arcor-ip.net) 17.22.39 # 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 # 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 # but that wastes a lot of memory, of course 17.22.45 # brb 17.23.40 # preglow: hmm, that's true.. but yes, it doubles the memory consumption 17.27.08 # 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 # That's so harsh 17.30.06 # I don't suppose anyone knows any projects similar to Rockbox for the SonyHD5 do they 17.30.52 # I don't know any projects similar to Rockbox. 17.31.35 # All I know is Rockbox, ipodlinux, and then various projects which hack linux-based devices 17.32.20 # 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 # Is the current PCM buffer as small as it can be, or could we reduce it? 17.34.41 # 19 pages left. 17.34.56 # 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 # linuxstb: can probably reduce it, but it's nice to have it largeish 17.51.41 # 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 # preglow: I only asked because at the start of the iriver port, we set everything much larger than needed. 17.54.08 # linuxstb: it's been reduced since then 17.54.19 # I should pay more attention :) 17.54.28 # can't follow everything 17.55.01 # rasher: Is the attachment problem solved now? 17.55.23 # Ah, apparently it is :) 17.55.30 # 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 # amiconn: excellent 17.56.34 # queen rocks 17.57.15 # amiconn: can't fix stereo width and channel config stuff at the moment thanks to apps/firmware clash 17.57.29 # amiconn: and btw, where do you actually set the 'custom' channel configuration? 17.58.09 # Slasheri: oh, and yes, why are the DSP_* constants put in playback.h of all places? 17.58.09 # (1) Hmm, what clash? (2) "Custom" uses the "Stereo width" percentage 17.58.40 # amiconn: what's about the recording bit-shift problem, any news? 17.58.44 # amiconn: stereo width and co are placed in sound.c, and i can't call dsp code from firmware code 17.58.59 # 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.02.47 # preglow: All channel configurations are handled in sound.c/set_channel_config() 18.03.22 # case SOUND_CHAN_CUSTOM: calculates the scaling factors for custom mode 18.04.01 # sound_set() calls this function in two cases 18.04.23 # The clash is in fact a difference in architecture 18.04.47 # yep 18.05.01 # For hwcodec, stereo width is part of the hardware settings just like volume, bass etc 18.05.13 # yes, indeed 18.05.25 # For swcodec it goes into an entirely different module 18.05.30 # all the settings we've implemented for iriver so far have been hardware based 18.05.33 # so no clashes 18.05.38 # Perhaps we should have a dsp_set() in apps/dsp.c 18.06.12 # ...and use that insetad of sound_set for "soft" settings 18.07.27 # 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 # After all, the stereo matrix settings of the mas are dsp settings, as is the pitch setting 18.08.08 # preglow: ah, i think there is no real reason for that. They can be moved to dsp.h 18.08.16 # Slasheri: ok, i'll try 18.08.19 # The mas is divided in 2 parts that are somewhat independent. 18.08.20 # good :) 18.08.43 # (1) The audio codec (2) The dsp 18.09.08 # amiconn: pitch change on mas isn't "gapless" ? 18.09.19 # Volume, balance, bass, treble, loudness, MDB are part of the dsp 18.09.27 # Err, part of the audio codec 18.10.07 # preglow: No, because the pitch shifting is done by "cheating" 18.10.12 # amiconn: yeah, i saw 18.10.18 # iriver pitch change will be seamless, at least 18.10.21 # amiconn: how long is the gap? 18.10.25 # We tell the mas a different clock frequency than it really has 18.10.45 # When pithcing up, we're effectively overclocking the MAS dsp 18.10.57 # but on the terratec who use the MAS too , the pitch feature work well 18.11.15 # The gap is a fraction of a second 18.11.29 # bobTHC: With or without gap? 18.11.41 # without and without disto 18.11.58 # bobTHC: well, yeah, but i'm certain they've got a proper pitch changing effect 18.12.06 # for sure 18.12.16 # 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 # bobTHC: Would be interesting to know how they do it 18.12.49 # iirc we've got some info on the MAS programming ? 18.13.50 # 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 # why amiconn ? 18.15.57 # iirc it was a [IDC]dragon announce... 18.17.04 # i found the thread => http://forums.rockbox.org/index.php?topic=587.msg2679#msg2679 18.17.43 # yes, it's true, but programming the mas is very hard 18.17.54 # This is about the pcm codec. I have that available 18.18.12 # 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 # The pcm codec is binary & accompanied by a datasheet similar to the standard MAS datasheet 18.19.20 # so pcm wave playback is possible ? 18.19.37 # Yes, and recording 18.19.43 # but what the deal with the bandwith ? 18.20.13 # Playback should be a no-brainer, as the serial bandwidth is 3MBit/s and it's fed via DMA 18.20.32 # oki 18.20.40 # 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 # ...and have to use a routine that "mimicks" DMA as the MAS parallel port is designed to use DMA 18.21.23 # ouch 18.21.36 # That's the one I'm struggling with... 18.22.00 # :) 18.23.14 # 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 # For pcm playback/recording on archos the HD will probably be spinning all the time 18.24.56 # and that can imply a quality limit... 18.25.12 # Why? 18.25.34 # (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 # if when we record the bandwith requiered for 44Hz is higher than the parallel port 18.28.19 # Ah, you mean the parallel port bandwidth 18.28.48 # It _should_ be sufficient for 44.1/16/stereo _if_ we manage to solve the bitshifting problem 18.29.41 # oki, nice 18.31.43 # 6 wikipages left 18.33.11 # all the worst ones, of course 18.33.40 # well, well 18.33.47 # 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 # amiconn: no eta on release yet? 18.54.16 # * rasher considers declaring WpsGallery "lots" 18.54.19 # "lost" 18.54.36 # There have been 150 updates since the backup :-\ 18.54.46 # rasher: i'd say let people fix that themselves 18.55.02 # YEah 18.55.16 # it's the easyest to refill imho 18.55.29 # 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.04.29 # So.. now only ManualMainMenu, WpsGallery, ReleaseTodo and TrackScreen are out of date 19.04.38 # ManualMainMenu is a beast. 19.04.56 # WpsGallery might as well be updated by people who put them there in the first place 19.05.22 # 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 # TrackScreen is just lost. 19.05.35 # 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.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 # Lear: yo, any reason for not thinking the ogg problem with the alloca is gone? 20.09.44 # 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 # Well, I have only had one ogg causing crashes, so I fixed that problem... 20.18.19 # And I tried using it in the simulator too, but I got link errors then, don't know why... 20.18.52 # (Not exactly sure what you mean with the first question, I must say... :) ) 20.18.56 # very strange, builtin_alloca is a compiler hint more than anything 20.19.10 # it's not an actual function 20.19.59 # you said in the post you thought you're not sure how complete the fix is 20.20.06 # just wondering what makes you think it's not complete 20.21.04 # 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 # 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 # 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 # i actually spotted that bug while away the last weekend 20.29.36 # but you beat me to it, heh 20.29.50 # the previous implementation was right out wrong 20.29.58 # and the current sim implementation still is 20.30.00 # 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 # Regarding builtin, aren't they all intrinsic (sp?) functions, i.e., stuff that generates code inline? Happens on target at least. 20.31.06 # they are 20.31.09 # so do alloca 20.31.13 Quit Sucka`away ("a bird in the bush is worth two in your house") 20.31.24 # it just keeps track of how much to subtract from the stack pointer when the function exits 20.31.38 # Anyway, didn't look closely at the sim problem; audio playback is a bit "shaky" there anyway... 20.31.39 # and that's how the automatic deallocation happens 20.31.45 # probably, never tried it 20.32.15 # but alloca for gcc is always #defined to __builtin_alloca via alloca.h 20.32.16 # Yeah, I know. There's some alignment stuff too. Nothing complicated or magic though. :) 20.32.33 # 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 # btw, do you know if the "rumours" of tremor on rockbox being more efficient than in the iriver fw is true? 20.34.41 # if so, we should really beat them into the ground with the additional 16kb of iram we don't use yet 20.36.37 # 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 # But you need to do something useful with those 16 kb... 20.37.00 # oh, indeed 20.37.06 # putting the entire floor decode in iram, for example :P 20.37.36 # 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 # We're compiling with -ffreestanding which implies -fno-builtin 20.37.53 # Maybe the FAAD code can be used right away? :) 20.38.11 # amiconn: for both sims and targets? 20.38.20 # 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 # in no way 20.39.07 # floor decode, the code you mean? 20.39.08 # as long as you spell it out to gcc 20.39.11 # Lear: yes 20.39.14 Quit Maxime (Read error: 104 (Connection reset by peer)) 20.39.14 # Lear: __builtin_alloca() should be available under this name, but not as alloca() 20.39.30 # ...unless you explicitly #define alloca 20.40.17 # Lear: i know code cache, etc etc, but it usually actually does make a difference 20.40.27 # Lear: and there's not much data left to be put in iram 20.41.07 # 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 # 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 # i believe it is, that's where the entire floor construction and dot product is done 20.42.10 # not 100% sure, of course 20.42.13 # besides 20.42.22 # there is some data malloced here and there that we can put in iram 20.42.27 # a lot of constant size mallocs 20.43.39 # 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 # And that function has been written in arm asm as well, so it might benefit from some attention... 20.45.00 # ehh 20.45.03 # that's a floor0 function 20.45.23 # in which case it isn't just a low quality ogg problem, it's a very-old-encoder problem 20.45.49 # 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 # Lear: yes, but it's still no way near libmad stack usage, no? 20.46.29 # Lear: in which case i don't see anything to worry about ;) 20.46.38 # Don't ask me. :) 20.47.28 # 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 # libmad has 90% usage 20.47.35 # hmm, well 20.47.43 # floor type 0 is only used by really old encoders, afaik 20.48.01 # 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 # 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 # Websense be damned! 20.51.14 # rasher, you were looking for me earler? 20.51.20 # 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 # Febs: It was something to do wiith WikiManual.. I figured it out - hadn't seen the mail at that point 20.55.52 # ok. I know that ManualMainMenu is going to be a nightmare ... I saw your earlier comment on that. 20.56.29 # That MainMenu thing should be split into several pages, IMHO... 20.56.31 # Yeah. It's pretty much the only one left 20.56.45 # Bit of a pain to edit something that large... 20.57.07 # lear, yes, I agree. 20.58.08 # Originally I had ALL of the menus in one page, but that grew too big so I split it into chapters. 20.58.40 # Menu menu is big enough now to require subchapters. 20.58.41 # i wish monty had used whitespace when he wrote tremor 20.58.47 # i hate reading source code with no whitespace 20.58.58 # reindent it? 20.59.30 # well, we should avoid modifying codecs 21.00.00 # oh right, I forgot that 21.00.32 # rather than simply restoring the previous ManualMainMenu page, I will take this opportunity to refine it. 21.01.26 # i think i'll go play libflac on tremor as well 21.01.40 # throw some calloced shit into static variables instead 21.01.54 # * preglow croons for a wav writer 21.03.02 # Lear: i wonder how much we should strive to support floor0 files 21.03.10 # no oggenc has made them since god knows when 21.03.13 # and we waste good iram there 21.03.17 # is or will there be any kind of "database browsing", such es listing by artists or genres? 21.03.28 # goa: there is 21.04.02 # preglow: ah sorry, the site seems to be online again, so i'll rtfm ;) 21.04.08 # Lear: ignore me, no idata in floor0 :> 21.04.17 # goa: do that 21.04.36 # yeah, sorry. 21.05.25 # no worries 21.05.33 # i'm not being harsh ;) 21.05.54 # ok =) 21.09.36 # 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 # Where are you reading this? Url? 21.10.07 # http://www.rockbox.org/twiki/pub/Main/RockboxManual/rockbox-manual-2.4.pdf 21.10.17 # page 87 21.10.19 # Ah, that's outdated 21.10.29 # mh :/ 21.10.35 # http://www.rockbox.org/twiki/bin/view/Main/NoDo 21.10.41 # thanks. 21.12.38 # erm, do i have a cache problem? the same sentence is there ;/ 21.12.54 # oh sorry, missed the "Archos line of players" 21.13.10 # 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 # 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 # Correct 21.30.07 # the devkit downloadable in the wiki is really not corresponding to the instructions, as someone pointed in the forum 21.32.12 # well 21.32.15 # wavpack supports ape2 21.32.27 # but i guess the db doesn't 21.32.30 # wiki question: is there any equivalent to the html COLSPAN function? 21.32.31 # a shame, 'tis 21.32.55 # I want a 3 column table ... 21.32.55 # what would be great would be the db gen being written in c and using the rockbox metadata parser 21.33.09 # Febs: horizontal merging? 21.33.17 # |foo|| 21.33.20 # |bar|baz| 21.33.23 # where columns B and C are combined in some instances 21.33.31 # that'll make foo span two cells 21.33.46 # (no space between ||) 21.34.12 Join linuxstb_ [0] (n=5343d4aa@labb.contactor.se) 21.34.27 # 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 # got it. It was the 'no space' that was throwing me off. 21.34.44 # thx. 21.34.48 # preglow: yup, i only have wavpack files here, that's why i asked ;) 21.35.13 # goa: well, rockbox supports ape2 in wavpack files, but the db generator doesn't, afaik 21.35.45 # preglow: mh, is there a donate button somewhere? =) 21.36.07 # goa: rockbox.org under the menu 21.36.10 # goa: sure, on the front page, downmost left 21.36.28 # omg, i'm blind.. 21.36.53 # 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 # 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 # i don't think you'll see any complaints on receiving a donation, no 21.47.16 # by god, is people unable to unsubscribe themselves these days? 21.48.08 # 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 # 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 # goa: thanks. $50 is lots, and very appreciated. 22.04.56 # <[IDC]Dragon> amiconn, have you located the recording loop in the archos s/w? 22.05.02 # goa: 50 is much for a donation, you're an angel 22.05.42 # <[IDC]Dragon> is that for backup tapes? 22.05.46 # :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 # simulator rule for designing wps :) 22.47.59 # ur the one who posted in my thread :p 22.48.03 # read my reply... 22.52.23 Join stripwax [0] (n=stripwax@i-83-67-214-206.freedom2surf.net) 22.52.27 # hey 22.53.42 # hshah, eheh yeah i replyed :) 22.58.40 # cool thanks Dma-Sc 23.00.47 # pretty nice that this tutorial/devkit exists, it saves time :) 23.01.44 # 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 # hshah : i can imagine that in packaging a clean devkit is quite apinful 23.07.30 # in > and 23.07.58 # rasher- how is the wiki restore coming along 23.08.04 # packaging devkit? 23.08.17 # Pretty much done, I'd say 23.08.47 # 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 # good work. 23.12.55 # 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 # Hola muchachos 23.54.19 # Well hello there 23.54.41 # o scuse 23.55.32 # what is the status of release please? 23.55.53 # Waiting for recording tests/fixes 23.56.03 # 1 month is so long :) 23.56.13 # what is wrong with it? 23.56.25 # Recordings break after a few hours 23.56.47 # planed to fix it, or release with? 23.57.02 # Hard to tell - the ball is amiconn's 23.57.14 # ah ok 23.57.28 # But he's not around much this week 23.57.33 # he is alone in this bug? 23.57.53 # Pretty much. 23.58.03 # alone working on it, want to tell