--- Log for 12.08.111 Server: hubbard.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 6 days and 0 hours ago 00.00.04 # ntfs supports that AFAIK 00.01.19 # i think this is some virtualbox trick where its driver is smart enough to expand the image file when it loads it 00.01.25 # sideral: no idea then 00.01.47 # saratoga: if you put that on the wiki it would probably be nice if we removed links to the outdated VM's since people seem to still download the oldest one and have trouble with it 00.01.47 # OK, thanks kugel! 00.02.14 # didn't we want to provide .debs of the compilers instead of VM images? 00.02.16 # n1s: yea i'm going to 00.02.24 # just hoping someone else could test it to make sure it works on other systems 00.02.42 # in case i somehow made it 64 bit only or something stupid 00.03.11 # saratoga: I've stumbled over some MP3 files that contain a lot of 0x55 (padding?) bytes after the ID3v2 header (after id3->first_frame_offset bytes), interspersed with some "LAME3.98." strings and other junk. Any idea what that might be? 00.03.23 # sideral: probably padding 00.03.40 # usually id3v2 tags are padded to the nearest 4k or 16k or whatever boundary 00.03.43 # saratoga: if i have time tomorrow i can try it on my netbook 00.03.51 # that way if someone adds a tag you don't have to rewrite the entire file 00.03.58 # does the codec know to ignore these bytes despite first_frame_offset pointing before them? 00.03.59 # (which is 32 bit) 00.05.33 # sideral: assuming its padding, it should, most id3v2 tags will have it 00.05.38 # if its something else then maybe not 00.05.54 # jhMikeS: how errno isn't thread-local is it? 00.06.34 # " The value of the padding bytes must be $00." 00.06.38 # hmm so maybe not padding 00.07.04 # could be part of embedded album art or something 00.08.23 # saratoga: Here's part of that data: http://pastebin.com/LisbiB0G 00.08.34 # kugel: no 00.09.26 # any reason for that? 00.09.32 # other than we don't bother? :) 00.09.45 # not that we use errno extensively 00.09.46 # I think nobody bothered 00.10.02 # sideral: doesn't look familiar to me, but i don't know much about ID3 00.10.21 # could this be part of an MPEG program stream? 00.11.37 # i don't think so 00.11.55 # the mpeg headers are small, and the contents of the stream itself are compressed and so would not have such low entropy sequences 00.12.10 # file says these tracks are Audio Data Transport Streams (ADTS) 00.12.15 # you could try opening the file in foobar and see what it reports 00.12.32 Quit domonoky (Read error: Connection reset by peer) 00.13.11 # Never used that program. Is it Win-only? 00.13.56 # yeah 00.14.16 # its kind of the gold standard 00.14.41 # what happens when rockbox loads this file? 00.15.00 # it just works 00.15.19 # mpg123 says there's a Xing header in there. what is that? 00.16.05 # VBR index thingy 00.16.32 # Xing headers are on pretty much all modern mp3 files 00.17.05 # usually a modern file has a xing header and a lame tag at the top 00.17.37 # maybe that's it? there's this strange LAME substring in there 00.19.13 # the usual headers are very short, pretty much just a few bytes identifing the file, some gapless info and a 100 entry seek table 00.20.50 # yeah, something like that is just before the 0x55 block 00.21.27 # if you're already like 5KB into the file, you're probably looking at the end of an id3v2 tag 00.21.34 Quit drezon (Read error: Operation timed out) 00.22.27 # The 0x55 extend 12 KB into the file 00.22.41 # also, I just noticed that there are more 0x55 at the end of the file 00.24.06 # I think there's a good chance that this is not ID3v2. I downloaded the file from Soundcloud, where there usually are no ID3 headers/footers, and tacked on the (short) ID3v2 header afterwards 00.25.51 # people do weird things to mp3 files since you can usually get away with it 00.25.55 # (just downloading it again to make sure) 00.26.08 # foobar at least should be able to strip and retag the stream 00.26.47 # huh 7zip compression is not as good if i use 10 threads instead of just 2 00.27.07 # maybe i can get that image under 500MB 00.28.46 Nick soap_ is now known as soap (~soap@rockbox/staff/soap) 00.28.49 # my motivation is that I'd like to ID tracks by CRCing a part of them (for fixing fuzzy DB resurrection), and those redundant parts give me duplicates 00.29.13 # so I'd like to know whether there's a way to find the real compressed audio data 00.29.25 # the mpeg headers let you know if you're looking at audio data 00.30.02 Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) 00.30.12 # although thats obviously MP3 specific 00.30.58 # I'd like to rely on whatever the metadata parser puts into the mp3entry structure 00.32.04 # but right now only the MP3 parser makes a half-assed attempt to identify the end of the header by filling in a non-zero first_frame_offset 00.32.19 # yea i think some of the logic is in mpa.c 00.32.45 # alternatively, you could look at the mp3 CRC, which is always at the start of the file and should be unique on almost all files 00.32.59 # although in theory someone could have decided to remove it 00.33.16 # interesting idea 00.33.38 # would be easy enough to have the metadata parser store it if it doesn't already 00.33.52 # yeah 00.34.01 # it has to parse that header anyway 00.34.09 # also mp3 specific though 00.34.12 # that would save the CRC computation at least for MP3 files 00.34.53 # i think vorbis has a crc too 00.35.17 # as do pretty much all lossless format 00.35.25 # how would streamable formats fill this in? 00.35.35 # it has a per page or packet or whatever they are called one but not sure about a whole file one but possibly 00.35.47 # ogg that is 00.36.16 # yeah so its just a crc of the start of the file, but should be unique since its hard to combine vorbis files in a way that renders them playable in rockbox :) 00.36.33 # hmm. problem is a CRC of the first few seconds is not enough, as many podcasts have the same audio intro 00.36.44 # that's on trap I already stepped into :) 00.37.13 # right now I'm seeking 10 KB into the file 00.37.32 # er, 1 MB 00.38.08 # try it and see 00.38.17 # i bet its rare to have an identical start even if the audio is the same 00.38.27 # I did try that, and I found dupes 00.38.37 # with the vorbis crc? 00.39.01 # no, with MP3-encoded podcasts, CRCing the actual audio data myself 00.39.13 # wow tweaking the 7zip parameters shaved ~60MB off the file size 00.39.27 # but you only CRCed a point 10KB into the file? 00.39.55 # would guess that you had tracks with the same embedded album art file :) 00.40.04 # I tried various points: directly after first_frame_offset, first_frame_offset + 4 KB, +10 KB, and +1 MB 00.40.47 # saratoga: No, I skipped behind any ID3 header (first_frame_offset does that much) 00.41.15 Join Scromple [0] (~Simon@115-64-195-104.static.tpgi.com.au) 00.41.27 Quit robin0800 (Remote host closed the connection) 00.41.30 # also, my podcast downloader shaves off any album art 00.42.11 # what is this crc'ing for? 00.42.15 # anyway, I got lots of dupes at offsets < 10 KB 00.42.19 Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) 00.43.10 # n1s: The context is FS#12076, where I now try to restore the fuzzy resurrection feature that I turned off before because it resurrected DB data for similar, but nonidentical tracks 00.43.11 # http://www.rockbox.org/tracker/task/12076 3Autoresume feature can start from wrong offset due to resurrection of old runtime stats (bugs, assigned) 00.43.56 # my approach right now is to ID the audio to tell similarly tagged tracks apart 00.44.07 # great, hwcodec seems to work with buflib as well 00.45.01 # http://duke.edu/~mgg6/rockbox/rockbox_virtualbox.7z 00.45.07 # smaller file 00.45.52 # sideral: so you want to store the crc in the db for each file and check it if a file moves? 00.46.04 Quit HaimN (Ping timeout: 240 seconds) 00.46.19 # right 00.46.31 Join HaimN [0] (~quassel@212.76.114.232) 00.47.06 # if too few tags match, I'd rerun the CRC and compare that 00.47.19 Join Thra11 [0] (~thrall@91.125.143.156) 00.49.56 # is 0xfffb an MPEG syncronization mark? 00.51.43 # random offsetts etc might hit some special location in some specific file type so i'd say full crc's is the way to go but the initial crc calculation when building the db would be sort of expensive 00.52.43 # yeah, that'd be too expensive. I'm already worried because seeking to 10 MB to avoid dupes might be taking to long. 00.53.00 # And the issue of skipping over any metadata the user might have changed in between remains 00.53.12 # many files won't be 10MB so you'd end up at the end of them too 00.53.13 # full crc if tags change, no? 00.53.21 # +fails 00.53.29 # so it'd have to be full CRC minus the metadata 00.53.33 # kugel: yeah but you need the crc to compare to 00.54.10 # the crc is meant as additional measure if the tags changed, iirc 00.54.10 # kugel: the idea is to find retagged, renamed tracks that are actually the same track as one the DB already knows about 00.54.39 # i've seen files with 1MB AA and such an album would probably get all identical crc's if you crc'ed a few kb at some offset in the image 00.54.54 # kugel: (The existing CRCs have another purpose. they're just hashes for tag strings that might not be in the DB any more.) 00.55.34 # n1s: I'd hope that AA would be skipped as metadata, that is id3->first_frame_offset would point after the AA 00.56.48 # yes it should, i thought you were doing file offsetts 00.57.09 # yeah, this won't work for small files. but those generally don't have the problem this is trying to solve, which seems to be fairly specific to podcasts (episodes with very similar metadata) 00.57.19 # audio offsetts hould be more reliable but you can still hit corner cases 00.58.22 # emulated and chip formats might also have identical parts that are not metadata though 00.58.39 # anyway, i think this kind of guesswork logic is a bad idea 00.58.50 # n1s: yeah, I ran into that as well with my atari chiptunes library :) 00.59.09 # n1s: i tend to agree 00.59.42 # but then i dont see lots of value in this resurrection 00.59.43 # I personally don't rely on fuzzy resurrection either, but roolku found it important enough to reopen the FS task 01.00.24 # (non-fuzzy) resurrection, though, is rather critical to have, because it's the only mechanism to recover DB data for tracks on removable media 01.01.14 # the point of this work is to reenable fuzzy resurrection by making it more precise 01.01.37 # by IDing the tracks with audio-data CRCs 01.02.44 # convincing people to drop fuzzy resurrection for good certainly would be easier than completing this work :) 01.05.50 Quit n1s (Remote host closed the connection) 01.33.12 Nick scorche` is now known as scorche (~scorche@rockbox/administrator/scorche) 01.35.29 Part Zagor 01.36.48 Join Thra11_ [0] (~thrall@113.190.pn.adsl.brightview.com) 01.40.35 Quit Thra11 (Ping timeout: 276 seconds) 01.44.15 Quit saratoga (Quit: Page closed) 01.46.51 Quit sideral (Quit: Leaving.) 01.55.58 Join SecretofMana [0] (~spiritofm@204.237.38.224) 01.56.34 *** Saving seen data "./dancer.seen" 02.03.24 Quit liar (Ping timeout: 258 seconds) 02.05.27 Quit Thra11_ (Ping timeout: 264 seconds) 02.11.36 Quit lebellium (Quit: ChatZilla 0.9.87 [Firefox 6.0/20110804030150]) 02.19.14 Quit mc2739 (Quit: leaving) 02.19.55 Join mystica555 [0] (~mike@216.58.116.195) 02.20.05 Join Thra11_ [0] (~thrall@113.190.pn.adsl.brightview.com) 02.20.52 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 02.27.39 Quit HaimN (Ping timeout: 264 seconds) 02.28.43 Quit Thra11_ (Quit: kthxbai) 02.34.38 Join Thra11 [0] (~thrall@113.190.pn.adsl.brightview.com) 02.37.20 Quit mc2739 (Quit: leaving) 02.40.47 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 02.41.02 Quit stripwax (Quit: http://miranda-im.org) 02.43.40 Join ChickeNE_ [0] (HydraIRC@99-133-145-177.lightspeed.cicril.sbcglobal.net) 02.47.34 Quit Thra11 (Ping timeout: 240 seconds) 02.50.36 Join bluefoxx_ [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) 02.51.43 Quit bluefoxx (Ping timeout: 240 seconds) 03.04.13 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 03.08.20 Quit bertrik (Quit: :tiuQ) 03.09.22 Quit mc2739 (Remote host closed the connection) 03.10.23 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 03.13.51 Quit robin0800 (Quit: Leaving) 03.17.02 Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) 03.19.54 Join mordocai [0] (~mordocai@mail.mordocai.net) 03.20.17 Quit robin0800 (Remote host closed the connection) 03.22.14 Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) 03.24.49 Quit mordocai (Quit: Leaving) 03.30.46 Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) 03.31.03 Quit Strife89 (Ping timeout: 252 seconds) 03.31.10 Join Strife89 [0] (~Strife89@207-144-19-39.cstel.net) 03.32.21 Quit robin0800 (Client Quit) 03.41.33 Quit MethoS- (Remote host closed the connection) 03.42.59 Quit markun (Ping timeout: 276 seconds) 03.56.36 *** Saving seen data "./dancer.seen" 04.25.46 Quit amiconn (Disconnected by services) 04.25.46 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.26.06 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.26.42 Quit pixelma (Disconnected by services) 04.26.44 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.26.46 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.27.12 Quit skx` (Ping timeout: 240 seconds) 04.27.30 Join skx` [0] (~skx@78-20-16-156.access.telenet.be) 04.33.04 Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) 04.42.53 Quit robin0800 (Quit: Leaving) 04.58.05 Quit [7] (Disconnected by services) 04.58.17 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 05.10.54 Quit sinthetek (Ping timeout: 252 seconds) 05.11.42 Join sinthetek [0] (~sinthetek@cpe-174-111-016-189.triad.res.rr.com) 05.11.42 Quit sinthetek (Changing host) 05.11.42 Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek) 05.20.36 Join pireau [0] (1000@pdpc/supporter/student/pireau) 05.32.43 Quit Horscht (Quit: Verlassend) 05.35.35 Quit ps-auxw (Ping timeout: 255 seconds) 05.37.45 Join Rob2222 [0] (~Miranda@p5DE4B182.dip.t-dialin.net) 05.39.23 Join ps-auxw [0] (~arneb@p4FF7EE4A.dip.t-dialin.net) 05.41.28 Quit Rob2223 (Ping timeout: 250 seconds) 05.56.38 *** Saving seen data "./dancer.seen" 06.23.06 Join jbeatty [0] (~jbeatty@c-75-64-73-152.hsd1.tn.comcast.net) 06.23.20 # is Rockbox 100% libre or does it contain proprietary firmware? 06.31.30 # 100% 06.32.01 # well... depends on how much you want to fight the FSF regarding GPL 06.32.11 # BSD code is libre 06.32.29 # gpl isnt 06.33.07 # freedom-for-users, not freedom-for-developers ;) it's a debate I'd be happy to indulge in if I had the time. 06.33.40 # at the moment I'm just trying to find a good media player for my younger brother without sacrificing principles 06.36.13 # your principles dont exten as far as IP protection? 06.37.38 # if people don't want to deal with the "viral" nature of the GPL, don't use GPL code 06.37.46 # it's really that simple. 06.38.18 # (but to be more to the point, no, I don't believe in "intellectual property") 06.39.29 # I <3 the GPL 06.40.01 # it basically establishes the community as a company in competition with all the vendors of proprietary software 06.40.13 # which IMO is what we need if we actually want to see open source *beat* proprietary software 06.40.16 # in the market 06.40.37 Quit SecretofMana () 06.40.41 # exactly, plus the GPL is an easy way for developers to firmly state "I do not want my code in proprietary products" 06.40.54 # which is the essense of the whole IP argument in the first place, right? developer desires? 06.41.09 # this is off topic, join #rockbox-community 06.41.46 Part jbeatty 06.42.40 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 07.20.21 Join stoffel [0] (~quassel@p57B49F87.dip.t-dialin.net) 07.28.32 Quit Strife89 (Read error: Operation timed out) 07.30.51 Quit wtachi (Ping timeout: 258 seconds) 07.43.17 Join JdGord [0] (~AndChat@122.110.244.206) 07.53.18 Join Buschel [0] (~chatzilla@p54A3ACDA.dip.t-dialin.net) 07.56.40 *** Saving seen data "./dancer.seen" 07.57.28 # New commit by 03buschel (r30282): Remove unused sources from libgme. 07.59.29 # r30282 build result: All green 08.00.27 Join HaimN [0] (~quassel@212.76.114.232) 08.05.59 Quit JdGord (Read error: Connection reset by peer) 08.06.13 Join JdGord [0] (~AndChat@122.110.244.206) 08.09.59 Quit powell14ski_ (Quit: powell14ski_) 08.13.47 Quit factor (Remote host closed the connection) 08.15.13 Quit stoffel (Remote host closed the connection) 08.16.06 Join B4gder [0] (~daniel@www.haxx.se) 08.16.06 Quit B4gder (Changing host) 08.16.06 Join B4gder [241] (~daniel@rockbox/developer/bagder) 08.18.31 Join sideral [0] (~sideral@rockbox/developer/sideral) 08.23.42 Quit Buschel (Quit: ChatZilla 0.9.87 [Firefox 3.6.18/20110614230723]) 08.30.08 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 08.36.02 Join factor [0] (~factor@74.197.205.204) 08.36.51 Join FoH_Phobos [0] (~foh@adsl-98-83-162-86.bhm.bellsouth.net) 08.48.18 Quit bluefoxx_ (Ping timeout: 260 seconds) 09.00.26 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 09.01.21 Join ender` [0] (~ender@foo.eternallybored.org) 09.08.36 Quit kadoban (Ping timeout: 258 seconds) 09.09.16 Quit JdGord (Quit: Bye) 09.14.10 Quit Scromple (Read error: Connection reset by peer) 09.15.04 Join petur [0] (~petur@rockbox/developer/petur) 09.15.27 Join lebellium [0] (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr) 09.16.33 Quit Keripo (Quit: Leaving.) 09.16.47 Quit sideral (Quit: Leaving.) 09.20.19 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 09.21.39 Join sideral [0] (~sideral@rockbox/developer/sideral) 09.24.00 Quit sideral (Client Quit) 09.27.02 Quit FoH_Phobos (Quit: ¡ooʇ ‘ǝןdoǝd ǝɹɐ sʇɐq) 09.34.02 Quit pixelma (Disconnected by services) 09.34.04 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 09.34.07 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 09.34.15 Quit amiconn (Disconnected by services) 09.34.15 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 09.34.35 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 09.37.54 Join n1s [0] (~quassel@rockbox/developer/n1s) 09.56.44 *** Saving seen data "./dancer.seen" 10.05.08 Join sideral [0] (~sideral@rockbox/developer/sideral) 10.16.12 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 10.21.49 Quit HaimN (Ping timeout: 258 seconds) 10.22.15 Join HaimN [0] (~quassel@212.76.114.232) 10.39.41 Quit God_Eater (Quit: Page closed) 10.41.01 Join God_Eater [0] (93722cc8@rockbox/staff/GodEater) 10.44.20 Join lorenzo92 [0] (~chatzilla@host18-111-dynamic.20-79-r.retail.telecomitalia.it) 10.48.39 Join pamaury [0] (~quassel@cez63-2-88-164-98-172.fbx.proxad.net) 10.48.39 Quit pamaury (Changing host) 10.48.39 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.50.20 Join markun [0] (~markun@s3eea32f5.adsl.wanadoo.nl) 10.59.34 Quit lorenzo92 (Quit: ChatZilla 0.9.87 [Firefox 5.0/20110622232440]) 11.07.34 Quit pamaury (Remote host closed the connection) 11.15.31 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 11.25.04 Quit Xerion (Read error: Connection reset by peer) 11.25.56 Quit kadoban (Ping timeout: 250 seconds) 11.38.22 Join mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de) 11.40.12 Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) 11.43.55 Join drezon [0] (~skeller@2a01:238:4200:7e03:f2de:f1ff:fe4f:3584) 11.51.10 Quit ChickeNE_ (Quit: Computer has gone to sleep.) 11.56.45 *** Saving seen data "./dancer.seen" 11.57.53 Quit robin0800 (Remote host closed the connection) 11.57.54 Join bluefoxx [0] (fuzzylomba@2002:4647:1f1f::4647:1f1f) 12.03.43 Quit HaimN (Ping timeout: 250 seconds) 12.04.12 Join HaimN [0] (~quassel@212.76.114.232) 12.47.13 Quit GigaBrick (Remote host closed the connection) 12.53.19 Quit petur (Quit: *plop*) 13.31.53 # * n1s ponders trying to clean up the codec optimization flag mess but is lacking good ideas. 13.32.37 # AFAICT we can do it like we do now, setting the flags directly in the makefiles or we could use #pragmas handled by the PP 13.33.05 # what advantage would #pragmas give? 13.34.01 # slightly easier to do them per arm generation without duplicating that stuff as make vars but not much else 13.34.42 # the big problem is that to be optimal we need a setting per arch(generation (for arm)) per codec 13.34.53 # atm it's only arm/cf/default 13.35.05 # I think a major drawback is that we don't have compiler flags outside the makefiles anywhere else (or do we?) 13.35.47 # i don't think so 13.36.25 # i don't think that we do that is. i agree it is a drawback as it's a bit non obvious that a header would set these flags 13.36.57 # yes. some ifdef magic in the makefiles should be able to do the same, no? 13.38.38 # probably 13.41.14 # that gets my vote then 13.41.22 # it would be neat to have it a bit centralized so you could set a default for an arch and define exceptions only where needed. can make do that? 13.41.37 # sure 13.42.52 # i wonder if something like that could go in the template stuff... 13.43.22 # i guess i need to read up a bit on make :) 13.50.26 Join antil33t [0] (~antil33t@124-197-33-15.callplus.net.nz) 13.55.54 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 13.56.35 # n1s: newer gcc allow pragma for optimization 13.56.49 *** Saving seen data "./dancer.seen" 13.56.51 # 4.5+ iirc 13.58.31 # I think you can define target-specific compiler flags in GNU Make, as in: plugin.o: OPTFLAGS = -Osomething # defines these OPTFLAGS for all dependencies of plugin.o 13.59.17 # look for "Target-specific Variable Values" in the make info doc 13.59.34 Join germanmushroom [0] (~remco@s5146db6a.adsl.wanadoo.nl) 14.03.49 Quit bluefoxx (Read error: Connection reset by peer) 14.04.11 Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) 14.04.55 Quit AlexP (Remote host closed the connection) 14.11.02 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 14.18.47 # kugel: yes i know, that's why i suggested it as a possible way to do it 14.19.07 # I would prefer that way 14.19.14 # why? 14.20.02 # according to the docs it works in 4.4 to otherwise it would be quite useless with our current arm toolchain 14.20.23 # but why do you prefer it over makefiles? 14.20.53 Quit antil33t () 14.21.25 Join AlexP [0] (~alex@rockbox/staff/AlexP) 14.23.08 # I dislike working with makefiles 14.23.51 # i do too but that is the only reason i can come up with :) 14.24.02 # isn't that enough? 14.24.33 # another reason is that changing the makefiles doesn't trigger a rebuild as changing the source files does, which very often trapped me 14.24.35 # unless you want to replace make with something else, splitting compiler options into more files isn't an improvement 14.26.00 # kugel: disliking something enough reason to prefer something else, sure, but it's usually not a convincing argument :) 14.27.34 # sideral: yes, that might come in handy 14.28.14 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 14.34.20 # Zagor: is the rule in codecs.make used for the files in a codec subdir if there's no special compilation rule in the subdir's .make? 14.48.47 # yes 14.49.05 # aha, thanks 14.49.13 # or, let me check 14.52.05 Join MethoS- [0] (~clemens@134.102.106.250) 14.52.09 # which directory has no .make? 14.53.07 # uh, no. i mean if there's no rule for making the .o' 14.53.13 # s in the .make 14.53.32 # for example http://svn.rockbox.org/viewvc.cgi/trunk/apps/codecs/libatrac/libatrac.make?r1=29042&r2=29041&pathrev=29042 14.54.28 # they are made with the default rules by adding them to OTHER_SRC, IIUC 14.54.37 # yes 14.54.55 # rules are path mathing and don't care where the makefile is located 14.54.59 # matching 14.56.05 # all files without explit rules are compiled by the general rule in root.make 14.56.19 # $(BUILDDIR)/%.o: $(ROOTDIR)/%.c 14.56.51 # aha, ok 14.58.17 # yikes, a <2min build round 14.59.33 # * kugel wonders if roolku considered to put the ccache on a ramdisk 14.59.58 # I did, but 4GB RAM is not enough :) 15.05.09 Join gilkup [0] (~gilkup@93-172-174-53.bb.netvision.net.il) 15.09.18 Quit gilkup (Client Quit) 15.16.03 Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) 15.23.29 Join wtachi [0] (~wtachi@cpe-069-134-168-033.nc.res.rr.com) 15.25.25 Quit n1s (Remote host closed the connection) 15.26.37 Quit robin0800 (Remote host closed the connection) 15.29.14 # We'd be buggered without roolku :) 15.29.30 Quit HaimN (Ping timeout: 246 seconds) 15.29.59 Join HaimN [0] (~quassel@212.76.114.232) 15.37.01 Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) 15.50.56 Join dunkaist [0] (~dunkaist@bp-203-106.dialup.vitebsk.by) 15.56.52 *** Saving seen data "./dancer.seen" 15.57.25 Quit B4gder (Remote host closed the connection) 16.03.01 Join lebellium_ [0] (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr) 16.04.29 Quit lebellium (Ping timeout: 258 seconds) 16.04.41 Nick lebellium_ is now known as lebellium (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr) 16.11.00 Quit simonlnu (Ping timeout: 258 seconds) 16.12.59 Join simonlnu [0] (2o6h3nYxGI@unaffiliated/simonrvn) 16.17.42 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 16.18.38 # AlexP: shh, don't tell this in public! :) 16.22.14 Join Horscht [0] (~Horscht@p5DD5779F.dip.t-dialin.net) 16.22.14 Quit Horscht (Changing host) 16.22.14 Join Horscht [0] (~Horscht@xbmc/user/horscht) 16.27.59 Quit robin0800 (Remote host closed the connection) 16.56.07 Quit HaimN (Ping timeout: 240 seconds) 16.58.32 Quit dunkaist (Ping timeout: 258 seconds) 16.58.46 Join Thra11 [0] (~thrall@209.190.pn.adsl.brightview.com) 16.59.55 Quit germanmushroom (Read error: Connection reset by peer) 17.02.24 # gevaerts: is there something you want to see (and I have perhaps forgotten about) before gsoc ends? 17.03.17 # I'm basically done with compaction enablement, so I'm testing right, and not sure if there's anything left to implement (since we yesterday agreed on not touching buffering for now) 17.09.10 Join dunkaist [0] (~dunkaist@82.209.203.197) 17.09.20 Join HaimN [0] (~quassel@212.76.114.232) 17.10.39 Join powell14ski_ [0] (~powell14s@c-174-51-194-6.hsd1.co.comcast.net) 17.14.24 Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) 17.15.41 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 17.17.45 # jhMikeS: ping 17.18.41 Part Zagor 17.24.11 # kugel: I'd like to see as much of your work committed as possible, but apart from that I can't really think of anything 17.26.48 Join fml [0] (~chatzilla@manz-590f186f.pool.mediaWays.net) 17.27.16 Join Xerion [0] (~xerion@5419A766.cm-5-2c.dynamic.ziggo.nl) 17.28.31 Join Thra11_ [0] (~thrall@148.14.113.87.dyn.plus.net) 17.29.09 # The order of file formats delivered by the wps tag %fc does not correspont to what is said in the manual. MP3 is not the third option. Is that a known bug? 17.31.47 Quit Thra11 (Ping timeout: 276 seconds) 17.40.08 Quit HaimN (Remote host closed the connection) 17.44.01 # fml: It seems to have been changed in r30225 17.44.08 # fml: But the manual wasn't updated 17.44.24 # I don't know if it affects any inbuilt wps 17.44.27 Join Thra11__ [0] (~thrall@87.113.230.201) 17.44.35 # Or if the wiki page was updated 17.45.34 # AlexP: what? The order of the results? 17.45.36 # fml: The order of the tag 17.45.36 # by kugel 17.45.36 # * fml looks... 17.46.41 # why has the order changed? 17.46.42 # I think new formats should go to the end 17.46.42 # It isn't new 17.46.42 # MP1 was moved out of the all players section at the start and put into the swcodec section afterwards 17.46.47 # ...but the site seems to be down ATM 17.46.50 Quit Thra11_ (Ping timeout: 258 seconds) 17.46.55 # So instead of mp1 mp2 mp3 it goes mp2 mp3 mp1 17.46.59 # I didn't think of that 17.51.21 # the commit can be remade to not break the order (not for swcodec at least) if needed 17.51.21 # fml: http://pastebin.com/3hFVVn3x 17.51.21 # kugel: It might be nice so we don't break any themes that use the tag 17.51.21 # Well, break is a bit strong 17.51.21 DBUG Enqueued KICK AlexP 17.51.21 # make incorrect :) 17.51.21 Quit Topy (Read error: Connection reset by peer) 17.51.21 # AlexP: ah, now I see. On the one hand, a particular order doesn't matter match. But OTOH it seems more logical if it's MP1, MP2, MP3. I think the patch could be done in a way that would preserve the order (with a bit more typing in the source). 17.51.21 # s/match/much 17.51.21 # Yes, it would be more logical, and it wouldn't make existing themes incorrect 17.51.21 *** Alert Mode level 1 17.51.21 # But it depends how much more complicated it makes it whether it is worth it 17.51.21 # fml: can you do that? busy atm 17.51.41 Quit logbot (Ping timeout: 252 seconds) 17.51.41 *** ERROR: (Closing Link: giant.haxx.se (Ping timeout: 252 seconds)) from hubbard.freenode.net 17.51.41 *** Cleanup 17.51.41 *** Cleanup 17.51.41 *** Saving seen data "./dancer.seen" 17.51.41 *** Exit 17.51.43 *** Started Dancer V4.16 17.51.43 *** Connected to irc.freenode.net on port 6667 17.51.43 *** Logfile for #rockbox started 17.51.45 Mode "logbot :+i" by logbot 17.51.49 *** Server message 501: 'logbot :Unknown MODE flag' 17.51.49 Join logbot [0] (~rockbox@giant.haxx.se) 17.51.49 Join Thra11__ [0] (~thrall@87.113.230.201) 17.51.49 Join Xerion [0] (~xerion@5419A766.cm-5-2c.dynamic.ziggo.nl) 17.51.49 Join fml [0] (~chatzilla@manz-590f186f.pool.mediaWays.net) 17.51.49 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 17.51.49 Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) 17.51.49 Join powell14ski_ [0] (~powell14s@c-174-51-194-6.hsd1.co.comcast.net) 17.51.49 Join dunkaist [0] (~dunkaist@82.209.203.197) 17.51.49 Join Horscht [0] (~Horscht@xbmc/user/horscht) 17.51.49 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 17.51.49 Join simonlnu [0] (2o6h3nYxGI@unaffiliated/simonrvn) 17.51.49 Join lebellium [0] (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr) 17.51.49 Join wtachi [0] (~wtachi@cpe-069-134-168-033.nc.res.rr.com) 17.51.49 Join MethoS- [0] (~clemens@134.102.106.250) 17.51.49 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 17.51.49 Join AlexP [0] (~alex@rockbox/staff/AlexP) 17.51.49 Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) 17.51.49 Join drezon [0] (~skeller@2a01:238:4200:7e03:f2de:f1ff:fe4f:3584) 17.51.49 Join mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de) 17.51.49 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 17.51.49 Join markun [0] (~markun@s3eea32f5.adsl.wanadoo.nl) 17.51.49 Join God_Eater [0] (93722cc8@rockbox/staff/GodEater) 17.51.49 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 17.51.49 Join sideral [0] (~sideral@rockbox/developer/sideral) 17.51.49 Join amiconn [0] (quassel@rockbox/developer/amiconn) 17.51.49 Join pixelma [0] (quassel@rockbox/staff/pixelma) 17.51.49 Join ender` [0] (~ender@foo.eternallybored.org) 17.51.49 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 17.51.49 Join factor [0] (~factor@74.197.205.204) 17.51.49 Join ps-auxw [0] (~arneb@p4FF7EE4A.dip.t-dialin.net) 17.51.49 Join Rob2222 [0] (~Miranda@p5DE4B182.dip.t-dialin.net) 17.51.49 Join pireau [0] (1000@pdpc/supporter/student/pireau) 17.51.49 Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek) 17.51.49 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 17.51.49 Join skx` [0] (~skx@78-20-16-156.access.telenet.be) 17.51.49 Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) 17.51.49 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 17.51.49 Join mystica555 [0] (~mike@216.58.116.195) 17.51.49 Join maraz [0] (maraz@kapsi.fi) 17.51.49 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 17.51.49 Join user890104 [0] (~Venci@83.228.31.135) 17.51.49 Join ender| [0] (~ender1@foo.eternallybored.org) 17.51.49 Join Elfish [0] (amba@2a01:4f8:100:90a1:abc:abc:abc:abc) 17.51.49 Join otih [0] (~otih@CAcert/Assurer/otih) 17.51.49 Join dre [0] (dre@gateway/shell/xzibition.com/x-iyvoeejaadvazojo) 17.51.49 Join fs-bluebot [0] (~fs-bluebo@g224238024.adsl.alicedsl.de) 17.51.49 Join pjm0616 [0] (~user@114.200.203.101) 17.51.49 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 17.51.49 Join yosafbri` [0] (~yosafbrid@li125-242.members.linode.com) 17.51.49 Join Utchybann [0] (~Utchy@rps6752.ovh.net) 17.51.50 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 17.51.50 Join scorche [0] (~scorche@rockbox/administrator/scorche) 17.51.50 Join FOAD [0] (~dok@83.161.135.61) 17.51.50 Join Kudo-san [0] (~kudo@wireless.sit-co.net) 17.51.50 Join preglow [0] (thomj@tvilling2.pvv.ntnu.no) 17.51.50 Join aevin [0] (eivindsy@unaffiliated/aevin) 17.51.50 Join user829385 [0] (~aoeu@112.166.15.141) 17.51.50 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 17.51.50 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 17.51.50 Join mikroflops [0] (~yogurt@h-34-156.a238.priv.bahnhof.se) 17.51.50 Join Staphylo [0] (staphylo@hyperion.epimeros.org) 17.51.50 Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 17.51.50 Join Bagder [241] (~daniel@rockbox/developer/bagder) 17.51.50 Join n17ikh [0] (~n17ikh@c-174-56-150-44.hsd1.sc.comcast.net) 17.51.50 Join rudi_s [0] (~simon@austria125.server4you.de) 17.51.50 Join Zambezi [0] (Zulu@unaffiliated/zambezi) 17.51.50 Join kugel [0] (~kugel@rockbox/developer/kugel) 17.51.50 Join ranmachan [0] (ranma@2a01:4f8:130:9321::2) 17.51.50 Join GodEater [0] (~bibble@rockbox/staff/GodEater) 17.51.50 Join jordan` [0] (~gromit@2001:660:3302:2826:225:90ff:fe20:d9a8) 17.51.50 Join tmzt [0] (~tmzt@adsl-99-164-33-12.dsl.akrnoh.sbcglobal.net) 17.51.50 Join Guinness [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) 17.51.50 Join ft [0] (efftee@shell.chaostreff-dortmund.de) 17.51.50 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 17.51.50 Join krazykit [0] (~quassel@li135-248.members.linode.com) 17.51.50 Join merbanan [0] (~banan@c-83-233-52-54.cust.bredband2.com) 17.51.50 Join bthomson [0] (~bthomson@c-68-33-5-232.hsd1.va.comcast.net) 17.51.50 Join Galois [0] (djao@efnet-math.org) 17.51.50 Join parafin [0] (parafin@paraf.in) 17.51.50 Join zu [0] (~zu@ks355000.kimsufi.com) 17.51.50 Join simabeis [0] (~simabeis@lobmenschen.de) 17.51.50 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 17.51.50 Join dionoea [0] (~dionoea@yop.chewa.net) 17.51.50 Join ukleinek [0] (~ukl@octopus.hi.pengutronix.de) 17.51.50 Join belak [0] (belak@subtle/user/belak) 17.51.50 Join bylzz [0] (~bylzz@arpnet.org) 17.51.50 Join soap [0] (~soap@rockbox/staff/soap) 17.51.50 Join [fred] [0] (fred@ircop.efnet.at) 17.51.50 Join neferty [0] (~andor@173.242.127.201) 17.51.50 Join guymann [0] (~charles@66-159-144-55.adsl.snet.net) 17.51.50 Join desowin [0] (~desowin@ip-69-162-133-251.static.chi2.systeminplace.net) 17.51.50 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 17.51.50 Join ruskie [0] (ruskie@sourcemage/mage/ruskie) 17.51.50 Join Torne [0] (~torne@rockbox/developer/Torne) 17.51.50 Join alexbobp [0] (~alex@108.60.198.57) 17.51.50 Join Hadaka [0] (~naked@naked.iki.fi) 17.51.50 Join eintopf [0] (eintopf@zzz.strace.org) 17.51.50 Join jfc [0] (~john@stat-bng-72-73-80-12.ngn.east.myfairpoint.net) 17.51.50 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 17.51.50 Join niekie [0] (~niek@CAcert/Assurer/niekie) 17.51.50 Join knittl [0] (~knittl@unaffiliated/knittl) 17.51.50 Join Espreon [0] (~espreon@wesnoth/developer/espreon) 17.51.50 Join ack` [0] (~ack@mingbai.org) 17.51.50 Join Slasheri [0] (miipekk@rockbox/developer/Slasheri) 17.51.50 Join Vimk [0] (~Vimk@fireslash.net) 17.51.50 Join bzed [0] (~bzed@devel.recluse.de) 17.51.50 Join crwl [0] (~crwlll@dsl-jklbrasgw1-ffb9c300-103.dhcp.inet.fi) 17.51.50 Join avacore [0] (~avacore@1008ds1-rdo.0.fullrate.dk) 17.51.50 Join jae [0] (~jae@dedicated.jaerhard.com) 17.51.50 Join iq_ [0] (~iq@ip24-252-19-172.om.om.cox.net) 17.51.50 Join ThomasAH [0] (~thomas@aktaia.intevation.org) 17.51.50 Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 17.51.50 Join CIA-14 [0] (~CIA@cia.atheme.org) 17.51.50 Join Barahir [0] (~jonathan@fb08schindler24.anorg.chemie.uni-giessen.de) 17.51.50 Join ved [0] (ved@ddsbox.co.cc) 17.51.50 Join scorche|sh [0] (~scorche@rockbox/administrator/scorche) 17.51.50 Join feisar-_ [0] (jljhook@ihq.in) 17.51.50 Join @ChanServ [0] (ChanServ@services.) 17.51.56 # No, sorry, not now 17.52.15 # kugel: You didn't update CustomWPS on the wiki either :) 17.52.38 # I think best would be just to put it back :) 17.54.38 Join Strife89 [0] (~Strife89@207-144-19-39.cstel.net) 17.57.12 Quit jhMikeS (Ping timeout: 250 seconds) 17.58.28 Join y4n [0] (y4n@unaffiliated/y4ndexx) 17.59.34 Nick Thra11__ is now known as Thra11 (~thrall@87.113.230.201) 18.00.10 # AlexP: as I said, I didn't think of it 18.00.19 # i.e. I was not aware that I changed the order 18.00.32 # so sure I didn't update CustomWPS 18.00.40 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 18.19.46 Quit dunkaist (Quit: leaving) 18.23.03 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 18.26.22 Join dunkaist [0] (~dunkaist@82.209.203.4) 18.27.34 Quit ender` (Quit: Saying time travel is impossible is a really safe bet. If it turns out time travel is possible, they can always go back in time and change their statement. But since they haven't changed their statement then that means time travel is impossible.) 18.27.37 Quit parafin (Remote host closed the connection) 18.27.48 Join parafin [0] (parafin@paraf.in) 18.28.07 Quit Keripo (Quit: Leaving.) 18.30.00 Join ender` [0] (~ender@foo.eternallybored.org) 18.30.56 Quit mikroflops (Ping timeout: 276 seconds) 18.32.22 Quit fml (Quit: ChatZilla 0.9.87 [Firefox 5.0/20110615151330]) 18.40.06 # kugel: Oh right, I didn't realise that is what you didn't realise :) 18.52.42 Join Stummi [0] (~Stummi@rockbox/developer/Stummi) 18.58.07 Join saratoga [0] (9803ec71@gateway/web/freenode/ip.152.3.236.113) 18.59.55 # kugel: about the resampler, I looked through the code only briefly and don't really understand it 19.00.13 # but it looks like the current implementation is really weird 19.00.25 # and i don't understand why it uses so much memory for what is basically a fairly small filter 19.01.26 # what's weird about it? :) 19.02.36 # It's actually pretty straight-forward, if you know how sampling and reconstruction works 19.05.17 # Well, at least I think it is pretty straight-forward. :) 19.05.39 # drezon: did you have a take on exploiting the symmetry? that'd halve memory usage 19.06.14 # No, I was pretty busy with real work. Maybe on the week-end. 19.06.19 # also switch to int16_t :) 19.06.32 # That only works if we drop a bit of precision 19.06.48 # *And* have sinc(0) at slightly less than 1 19.06.59 # why _and_? 19.07.02 # Because it's signed 19.07.11 # oh right 19.07.14 # I forgot about that-- 19.07.31 # it's not signed if you do the symmetry :) 19.07.42 # no wait, nevermind 19.07.49 # :) 19.08.31 # but yea, 30k sounds like an awful lot for what it does 19.09.12 # As I wrote we can halve that, if we calculate the sinc on-the-fly (i.e. don't have the huge static table anymore) 19.09.31 # I just don't know (yet) how to use fp_sincos for that 19.09.35 # the tables are alternating positive and negative 19.10.00 # pretty sure you can do the signedness differently 19.10.03 # lol.. yea we could exploit that 19.10.33 Join mgue [0] (~mgue@p5DDA3E17.dip.t-dialin.net) 19.10.34 # subtract every second term instead of add 19.10.46 # Yes, should be doable 19.12.08 # So if we go for int16, calculate the sinc and use the symmetry we're at ~4K or so 19.12.25 # that sounds a lot better than 30k :) 19.14.52 # I'm not sure calculating the sinc is a good idea though 19.16.30 # But the exploiting the signedness only works for upsampling as the sinc is streched for downsampling and thus it is not easily clear where the sinc gets negative 19.17.28 # drezon: i still don't understand why you need such a large trig table with such complicated indexing? 19.18.04 # using int16 is awkward since armv4 doesn't have a good hardware instruction for multiplying by a 16 bit value 19.18.15 # it makes sense on armv5+ though 19.18.49 # surely armv4 can use 32bit mul for 16bit if it's faster? 19.18.55 # Can't you just sign-extend to 32bit in the register? 19.19.51 # drezon: streched or not, the sign depends on the index (modulo 2) for the table, no? 19.21.28 # Currently, yes. But if we calculate the sinc the stretched sinc would be calculated to use the whole table (to get rid of sinc_increment) and then it's not that clear anymore 19.22.40 # kugel: you can, but you have to use shifts and ands 19.22.44 # so its slower 19.23.03 # * kugel doesn't see that 19.23.14 Join Buschel [0] (~chatzilla@p54A3AE1C.dip.t-dialin.net) 19.23.16 # armv5 adds a multiplication instruction that references the top or bottom half of a register 19.23.18 Quit sideral (Quit: Leaving.) 19.23.19 # saratoga: how else would you handle resampling? The code get's the sinc values for the 15 samples at real time t (between sample at current and current+1) and adds them. Just as the reconstruction low-pass would create the analog signal at the time t. 19.23.47 # saratoga: it's still 16x16, just that the bits are sign-extended 19.23.50 # drezon: isn't this resampler just a convolution of sinc with our input data? 19.23.57 # the result is still 32bit so no need for shift 19.24.05 # That "between current and current+1" is the 8 bit fractional part and the second array index 19.24.19 # kugel: if you store them as an array of 16 bit values each register has two 16 bit ints in it 19.24.38 # huh? 19.25.00 # Kudo-san: probably there are only 32bit loads? 19.25.07 # kugel i meant ;) 19.25.27 # armv4 has half-word loads IIRC 19.25.59 # kugel: it does, but you want to use load multiple 19.26.13 # otherwise you will need 2x the loads, and each will also be 2x slower 19.26.44 # you're at asm already aren't you? :) 19.26.54 # yes :) 19.27.09 # well predicting how gcc will handle this 19.27.20 # I predict gcc does not do that :) 19.27.24 # basically if you try this with 16 bit values it will probably get a lot worse even in c 19.28.02 # although maybe android would be different given all the stuff new arm cpus can do 19.28.09 # one load + shift + and is still faster than 2 loads 19.28.23 # saratoga: it is, but you need the result of that convolution between two sample values. And one (less efficient) way would be to insert as many zeros as needed between samples, then filter. Another way is what I do: calculate the superposition. 19.28.38 # hm, perhaps not with ldm 19.28.54 # if this is just a convolution, i don't understand why we can't just precompute the taps and store them sequentially in memory? 19.29.20 # indexing by (fractional!) amounts with fixed point math is going to absolutely kill performance 19.29.27 # its probably not all that accurate either 19.29.41 # essentially every load is going to be a cache miss 19.31.51 # Because we go through the sinc by some fractional increment. In the worst case this has a period of 256, so we'd need all 15*256 coeffs anyway (access would be linear, though). Granted this would only be the case for up sampling by 256. 19.32.06 # but we know the ratio in advance 19.32.18 # so why compute the index on every single sample rather then just do it once in advance? 19.34.59 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 19.35.08 # The 8 bit index changes on every sample (it's + increment fractional part % 256). This change is periodic. In the worst case with a period of 256. 19.36.36 Quit Xerion (Read error: Operation timed out) 19.36.56 # If this is about cache miss: I optimized similar code for x86 by using SSE and reversing the sinc index. I left it at [15][256] because it's easier to understand what's being done. But we could easily reverse this. Then the access would be linear per sinc_upsample() call 19.37.01 Quit fs-bluebot (Ping timeout: 255 seconds) 19.37.30 # yes the index order are backwards, but thats not the biggest issue with doing this efficient 19.37.35 # drezon: is there some source for the algorithm itself? maybe i just don't understand how this is different then ordinary convolution 19.37.48 # And if we precalc for downsampling. Same would be for downsample 19.38.11 Join fs-bluebot [0] (~fs-bluebo@f053153091.adsl.alicedsl.de) 19.38.20 Quit bluebroth3r (Ping timeout: 246 seconds) 19.39.26 # saratoga: I "invented" this algorithm myself. It's simply what the reconstruction low-pass does. So there is no source that I know of. 19.41.44 # But I'm pretty sure I'm not the first doing this. Actually I would think all oversampling DACs do this in hardware. 19.41.56 # they do, although they implement it somewhat differently 19.42.05 Join stoffel [0] (~quassel@p57B4A84C.dip.t-dialin.net) 19.42.09 # usually they first upsample a lot by inserting zeros, and then use a conventional low pass filter 19.42.22 # Really? 19.42.36 # yeah 19.42.47 # I would do it my way. :) 19.42.53 # i guess the difference that i'm missing here is that you're doing the lowpass and interpolation step at once 19.42.53 Quit dunkaist (Quit: leaving) 19.43.00 # Exactly 19.43.14 # so you need to oversample your kernel since you'll be hitting different point on it with each sample 19.43.22 # Yes! 19.44.02 # so basically it is convolution, but not over the input samples exactly, but over the zero padded version of them 19.46.11 # heh and the least common multiple in the 48 to 44.1k case is 147 times the base rate 19.46.50 # alright well now i understand why everyone uses polynomials instead of sinc resampling for embedded devices :) 19.46.54 # So I serached a bit and found this: https://ccrma.stanford.edu/~jos/resample/ 19.46.58 Quit Bagder (Ping timeout: 276 seconds) 19.47.11 # I think they do something similar to what I implemented 19.47.45 # Only quickly glanced through it, though 19.48.49 # yeah i understand now 19.49.08 # i was missing that the huge LCM between the sampling rates means you need to very finely sample the convolution kernel 19.51.41 # \o/ dircache runtime switchable 19.51.46 *** Saving seen data "./dancer.seen" 19.53.11 # saratoga: maybe it would have been easier if I provided my x86 source as that one has an init() function which calculates the sinc. So it's easier to see that we sample it between zero crossings. 19.59.39 Quit jae (Read error: Operation timed out) 20.00.39 Join jae [0] (~jae@dedicated.jaerhard.com) 20.30.10 Join mikroflops [0] (~yogurt@h-34-156.a238.priv.bahnhof.se) 20.49.15 Quit kadoban (Ping timeout: 260 seconds) 20.49.28 Quit drezon (Ping timeout: 255 seconds) 21.06.46 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 21.16.54 Join Thra11_ [0] (~thrall@84.93.149.190) 21.17.22 Quit Thra11 (Read error: Operation timed out) 21.17.35 Nick Thra11_ is now known as Thra11 (~thrall@84.93.149.190) 21.25.48 Quit stoffel (Ping timeout: 252 seconds) 21.28.04 Join simonlnu_ [0] (7ziUFtAAq4@unaffiliated/simonrvn) 21.31.04 Quit simonlnu (Ping timeout: 258 seconds) 21.31.12 Nick simonlnu_ is now known as simonlnu (7ziUFtAAq4@unaffiliated/simonrvn) 21.31.46 Join Farivan [0] (~chatzilla@12.20.4.100) 21.38.31 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 21.42.45 Quit stripwax (Ping timeout: 240 seconds) 21.46.17 # did anyone try my new virtualbox image? curious if its working for other people 21.48.59 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 21.49.35 # AlexP, kugelp: Changing the order back for swcodec will make themes incompatible between hwcodec and swcodec 21.50.34 Part Farivan 21.51.49 *** Saving seen data "./dancer.seen" 21.53.08 # bloody hwcodec 21.53.22 # at the least it should be mp3, mp2, mp1 then 21.53.39 # It is just a shame it will make people's themes wrong 21.54.18 # Maybe mp3 mp2 mp1 makes more sense 21.54.43 # One day themes will be incompatible between hwcodec and swcodec anyway (if we don't break order again) 21.55.07 # We've had changes that made themes not work at all without doing much to help. I don't really see the problem with changing something that I suspect most people won't even look at and documenting that change 21.55.28 # gevaerts: It isn't a massive issue, I was just trying to avoid it 21.55.39 # But if it can't be avoided, then so be it 21.56.09 # AlexP: maybe we can get JdGordon to make a breaking change at the same time? :) 21.56.21 # heh, has he got one coming up by any chance? :) 21.56.27 # No idea 21.58.37 Quit Stummi (Quit: Bye!) 22.13.24 Quit liar (Read error: Connection reset by peer) 22.16.25 # amiconn: really? 22.16.44 Quit Thra11 (Ping timeout: 252 seconds) 22.16.45 Join mercutio22 [0] (~mercutio2@cpe-68-173-63-113.nyc.res.rr.com) 22.17.08 # could make mp2 start at 2 for hwcodec? 22.17.11 # Hi. Can someone recommend me a device to use with rockbox? I am off to buy one right now 22.19.33 # I heard good shit about the iriver devices 22.20.53 Join sideral [0] (~sideral@rockbox/developer/sideral) 22.21.45 Join JesusFreak316 [0] (~JesusFrea@pool-173-65-77-157.tampfl.fios.verizon.net) 22.21.47 # mercutio22: you'll have to be a bit more specific about what you care about 22.24.15 Join dunkaist [0] (~dunkaist@bp-183-23.dialup.vitebsk.by) 22.25.52 Quit y4n (Quit: The world around me drops away, replaced by worlds being created and destroyed by my imagination.) 22.30.32 Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) 22.30.33 Quit Bagder (Changing host) 22.30.33 Join Bagder [241] (~daniel@rockbox/developer/bagder) 22.31.15 Join Thra11 [0] (~thrall@80.229.120.221) 22.39.56 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 22.45.00 # gevaerts: I just want a long battery life and plenty of space. I don't care about video. 22.46.46 # it seems like the sansa fuze is the only compatible one still in production 22.46.53 # http://www.rockbox.org/wiki/BuyersGuide 22.47.32 # Maybe the clip too, but I'm not sure 22.47.58 # what does plenty of space mean to you? 22.48.05 # ditto long battery 22.48.16 # Make sure you don't get a fuze+ though, unless you want to work on the port instead of actually using it 22.49.08 # battery life should last around 12 hours and space should be ~ 30-40 gb 22.49.29 # OK, so clip+ or fuze with a big µSD would do 22.49.38 # Maybe 22.49.45 Join ChickeNES [0] (~ChickeNES@rouxbicon.rh.uchicago.edu) 22.49.45 # Can you get 32 GB µSD yet? 22.50.20 # For that space you might need to look at HDD players 22.50.21 # actually... its ok to have less and latter upgrade microSD cards 22.50.48 # or whatever kind of memory card 22.51.16 # so looks like its narrowed to the sansa fuze v2 22.51.32 # where could I find it? 22.51.35 # or clip+ 22.51.39 # I don't know 22.51.46 # I don't even know what country you are in 22.53.11 # I am in NYC right now. I am looking at bestbuy right now. Let me know if anyone has any clues 22.53.18 # USA then? 22.53.25 # In which case I have no idea 22.53.45 # the fuze isn't in production FYI 22.54.03 Quit stripwax (Read error: Connection reset by peer) 22.54.25 Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) 22.54.59 # oh shit 22.55.18 # ={ 22.56.12 # I guess I can't get anything that runs rockbox that isn't apple then 22.57.14 # ok 22.57.26 # "not in production" doesn't have to mean "not available" 22.58.25 # yea, but I am in NYC for just a couple of days... I can't order, bell is broken and outta home all day ={ 23.00.33 # clip+ is I think 23.01.44 # lets see if I can find the clip+ 23.02.57 # Thanks! I see in their website they might have it! 23.03.05 # I will go have a look 23.04.22 Join B4gder [241] (~daniel@rockbox/developer/bagder) 23.04.52 Quit Bagder (Ping timeout: 264 seconds) 23.08.19 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 23.09.33 Quit mercutio22 (Ping timeout: 276 seconds) 23.11.03 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 23.16.07 Quit Horscht (Ping timeout: 250 seconds) 23.17.23 Quit benedikt93 (Quit: Bye ;)) 23.26.26 Join drezon [0] (~skeller@dslb-088-073-110-032.pools.arcor-ip.net) 23.36.31 # New commit by 03buschel (r30283): 6th part of FS#12176. Reduce memory consumption of libgme emulators to allow enabling of NSF and SGC codecs for low memory targets. The main lookup ... 23.38.58 # r30283 build result: All green 23.42.36 Join mshathlonxp [0] (~amdk7powe@5ad4ef88.bb.sky.com) 23.51.52 *** Saving seen data "./dancer.seen" 23.53.12 Quit stripwax (Quit: http://miranda-im.org) 23.54.52 Quit dunkaist (Quit: leaving)