--- Log for 24.07.113 Server: hitchcock.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 3 days and 10 hours ago 00.01.47 Quit Strife89 (Quit: Heading out.) 00.05.20 Quit onder` (Quit: leaving) 00.05.58 Join onder` [0] (~onder@24.244.89.228) 00.07.48 Quit EstebanMonge (Ping timeout: 240 seconds) 00.24.33 Quit efyx (Quit: Quitte) 00.29.22 Join EstebanMonge [0] (~emonge@200.110.251.210) 00.31.57 Join Strife89 [0] (~Strife89@adsl-98-80-213-146.mcn.bellsouth.net) 00.32.22 Quit pamaury (Ping timeout: 246 seconds) 00.45.09 Part EstebanMonge 00.50.02 Join arcaicofl [0] (~fluxo@201-29-253-189.user.veloxzone.com.br) 00.52.02 Quit arcaicofl (Max SendQ exceeded) 00.52.31 Join arcaicofl [0] (~fluxo@201-29-253-189.user.veloxzone.com.br) 00.53.56 Quit mindflash (Ping timeout: 276 seconds) 01.04.34 *** Saving seen data "./dancer.seen" 01.10.44 Part ZincAlloy 01.12.22 Quit gelraen (Read error: Connection reset by peer) 01.12.40 Join gelraen [0] (~imax@mail.univua.net) 01.20.06 Quit liar (Ping timeout: 245 seconds) 01.35.17 Join JdGord [0] (~AndChat72@pa49-176-70-180.pa.nsw.optusnet.com.au) 01.47.16 Quit arcaicofl (Quit: Saindo) 01.49.50 Quit JdGord (Ping timeout: 276 seconds) 01.50.29 Join JdGord [0] (~AndChat72@pa49-176-70-180.pa.nsw.optusnet.com.au) 02.00.14 Quit JdGord (Ping timeout: 276 seconds) 02.00.36 Join JdGord [0] (~AndChat72@pa49-176-70-180.pa.nsw.optusnet.com.au) 02.02.22 Join AndChat|72624 [0] (~AndChat72@vl10.gw.ok-labs.com) 02.06.02 Quit JdGord (Ping timeout: 256 seconds) 02.11.31 Join belak [0] (~belak@facebook/engineering/belak) 02.30.58 Quit AndChat|72624 (Quit: Bye) 02.31.11 Join JdGord [0] (~AndChat72@vl10.gw.ok-labs.com) 02.31.14 Quit JdGord (Client Quit) 02.32.55 Quit Strife89 (Quit: This computer has gone to sleep) 02.33.28 Join tertu [0] (~tertu@65-128-181-81.mpls.qwest.net) 02.36.57 # <[Saint]> copper: *required* to bitch about it? :) 02.37.22 # <[Saint]> It doesn't seem like you mind that requirement. 02.38.48 # <[Saint]> copper: please don't confuse the EQ and volume step, you may have missed it, but, the two are unrelated. 02.39.31 # <[Saint]> I first thought they were not, it seems as though the volume step change would've happened if the EQ resolution wasn't changed anyway. 02.48.44 Join uwe__ [0] (~uwe_@dslb-088-064-049-075.pools.arcor-ip.net) 02.52.27 Quit uwe_ (Ping timeout: 245 seconds) 03.04.38 *** Saving seen data "./dancer.seen" 03.43.25 Quit belak (Quit: belak) 04.02.33 Quit [Saint] (Remote host closed the connection) 04.03.38 Join [Saint] [0] (~saint@rockbox/user/saint) 04.25.05 Quit bzed (Remote host closed the connection) 04.25.05 Join bzed [0] (~bzed@devel.recluse.de) 04.33.22 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.33.22 Quit amiconn (Disconnected by services) 04.33.22 Quit pixelma (Disconnected by services) 04.33.22 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.33.23 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.33.27 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.49.42 Join dell [0] (~dell@ool-435622d3.dyn.optonline.net) 04.49.44 Quit dell (Client Quit) 04.49.57 Join dell [0] (~dell@ool-435622d3.dyn.optonline.net) 05.04.43 *** Saving seen data "./dancer.seen" 05.11.47 Join Strife89 [0] (~Strife89@98.80.213.146) 05.23.45 Join JdGord [0] (~AndChat72@pa49-176-65-74.pa.nsw.optusnet.com.au) 05.28.17 Quit JdGord (Ping timeout: 264 seconds) 05.33.41 Quit dell (Quit: Ex-Chat) 05.34.24 Join skofo [0] (~skofo@75-39-233-255.lightspeed.prrgil.sbcglobal.net) 05.34.33 # Hello 05.39.13 # I am having a hard time using a bitmap in my plugin 05.41.19 Quit Strife89 (Quit: Vamoose!) 05.41.43 Join Strife89 [0] (~Strife89@adsl-98-80-213-146.mcn.bellsouth.net) 05.44.40 # Ah, found the issue. 05.46.48 Join belak [0] (~belak@facebook/engineering/belak) 05.48.24 Join amayer [0] (~amayer@72.25.17.110) 05.49.01 # Bwahaha 05.49.13 # \q 05.49.19 Quit skofo (Quit: leaving) 05.51.43 Quit [7] (Disconnected by services) 05.51.52 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 06.15.55 Quit shamus (Read error: Connection reset by peer) 06.16.49 Join shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net) 06.24.30 # i get an error when trying to compile a simulator. i ran tools/configure. then make && make fullinstall. the error i get is tools/bmp2rb: not found. it happens right after the line that says BMP2RB rockboxlogo.320x240x16.bmp 06.24.48 # do i need to compile bmp2rb first? 06.29.16 # <[Saint]> No. 06.29.44 # <[Saint]> As you said, "BMP2RB rockboxlogo.320x240x16.bmp" means that already happened. 06.30.12 # <[Saint]> You're not running make with -j *? 06.30.36 # no i didnt use -j 06.31.04 # <[Saint]> which sim? 06.31.07 # and the BMP2RB comes first then the error that says tools/bmp2rb: not found 06.31.11 # Ipod Video 06.32.25 # <[Saint]> just trying now, won't be long. 06.33.36 # im running Ubuntu 13.04 ive compiled tons of times on 12.04 but the first time i try on 13.04 i get errors 06.34.35 # <[Saint]> 13.10 here, no error. 06.34.42 # <[Saint]> "make veryclean", try again. 06.37.05 # i believe its failing on "make" not "make fullinstall" 06.37.17 # ill try again 06.38.10 # <[Saint]> yes, it will be. try make veryclean, then re-run make. 06.44.42 # [Saint], still generating dependencys... im not ignoring you 06.51.54 # [Saint], it seems to be working now 06.52.00 # what does make veryclean do? 06.53.26 # <[Saint]> trashes everything in the build dir except for the files generated by configure, iirc. 06.53.48 # <[Saint]> Its likely you had leftovers from a failed build, or a build from another target device. 06.54.59 # hmm... i ran "rm -R ./*" before i did ../tools/configure 06.55.50 # <[Saint]> odd. 06.57.05 # ill say 06.57.12 # well thank you for your help :) 06.57.33 # [Saint], I had some difficulties with building the Android .apk earlier that I believe you've helped with before. 06.58.05 # If you have time later, I'd like to try to fix it 06.58.09 # <[Saint]> Strife89: http://forums.rockbox.org/index.php?topic=43260.0 06.58.42 # Ahhh. 06.58.51 # <[Saint]> I should edit that post slightly so it isn't necessary to download API16 06.59.11 # I'll follow that in the morning, then. 06.59.21 # Thanks. 06.59.22 # <[Saint]> just install the SDk as-is, and then symlink adnroid-16 to android-17 in the platforms dir 07.00.10 # <[Saint]> alternatively, download android-16, but it seems odd to do so if RaaA will build anyway and the SDK comes with android-17. 07.02.11 # <[Saint]> the long and the short of it is 2 files we rely changed their location, and one is completely missing. :) 07.04.47 *** Saving seen data "./dancer.seen" 07.19.41 Quit amayer (Quit: Leaving) 07.48.59 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 07.49.30 Quit shai (Read error: Connection reset by peer) 07.57.59 Join ZincAlloy [0] (~Adium@pD9EE8BBD.dip0.t-ipconnect.de) 07.59.58 Join [Saint_] [0] (~saint@rockbox/user/saint) 08.01.37 Quit [Saint] (Disconnected by services) 08.01.43 Nick [Saint_] is now known as [Saint] (~saint@rockbox/user/saint) 08.12.08 Join ender` [0] (krneki@foo.eternallybored.org) 08.13.01 Quit Scall (Quit: Bye bye) 08.15.21 Join melmothX [0] (~melmoth@unaffiliated/melmothx) 08.32.33 # [Saint]: volume step and EQ step are the same concern 08.33.20 # <[Saint]> No, they're not. 08.34.28 # <[Saint]> When I looked initially, I messed up, I thought I had a part in the volume mess - I didn't. 08.34.43 # <[Saint]> Whatever the EQ step is, the volume would still be broken at this point. 08.35.48 Quit bluebrother (Disconnected by services) 08.35.53 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 08.36.56 # <[Saint]> copper: you even responded to an email in the ML that states the two are unrelated. 08.36.59 # <[Saint]> Did you read it? 08.37.04 # [Saint]: they're the same concern, usability-wise 08.37.18 # <[Saint]> No. 08.37.22 # Yes. 08.37.49 # Why do you think they're not? 08.38.10 # <[Saint]> Its not the same concern at all. You seem to think it is deliberate. The volume resolution could be 0.0000000001dB, and it would be entirely transparent to the user. 08.38.28 # <[Saint]> The fact it isn't is an error. Not deliberate. Nor is the EQ concerned here. 08.38.41 # … 08.38.51 # *I* am concerned with the EQ steps as well. 08.39.00 Quit fs-bluebot (Ping timeout: 248 seconds) 08.39.09 # <[Saint]> That doesn't make the two related. 08.39.18 # I'm not saying they are 08.39.29 # <[Saint]> As stated in the ML, bring it up in an appropriate thread. 08.39.30 # but it's the same usability problem 08.39.51 # <[Saint]> I doubt you will, though, as you threw your toys in that thread. 08.40.00 # can you blame me? 08.40.05 # <[Saint]> I'm willing to be surprised, though. 08.43.59 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 08.44.07 # * GodEater tries to work out how to change his password on the forums 08.44.24 # <[Saint]> Worth noting is that if you updated your build, you wouldn't see any issue. 08.44.53 # <[Saint]> ...well, besides the EQ, which you've stated you don't use any more than the config you already have there. 08.44.59 # ah - there we go 08.45.41 # <[Saint]> pamaury changed the volume resolution for the F+ back to what was expected, not really a fix, more a sidestep. 08.46.49 # <[Saint]> I would've prefered g#519 be committed personaly, but I think pamaury just wanted people to stop thinking *he* broke this. 08.47.19 # * [Saint] whistles for fs-bluebot 08.47.30 # <[Saint]> ...where is that lazy bastard? :P 08.47.47 # not here ;) 08.47.58 # [Saint]: posted 08.49.30 # <[Saint]> I'm sure that it will be brought up in the ML, but the fact that the internal stepping == .1dB isn't the issue here. 08.49.39 # <[Saint]> (re: volume) 08.49.50 # <[Saint]> That should be entirely transparent to the user. 08.49.55 # the UI is the issue 08.50.17 # indeed, I don't care what you use "internally" 08.51.08 # <[Saint]> I'm sure this will be brought up in the ML as well, as it was in here, but the "magic config option" won't happen. 08.51.15 # <[Saint]> That's a very big "No No" here. 08.51.20 # what's that? 08.52.11 # <[Saint]> " on IRC, proposed that such fine-grained values be accepted in the configuration file, but not reflected in the user interface. That sounds perfectly acceptable to me, and would probably satisfy the most "enthusiastic" users, without bugging everyone else" 08.52.21 # <[Saint]> that. 08.52.22 # fine 08.52.32 # I'm not the one who would care about that 08.52.38 # <[Saint]> Yeah, I know it doesn't bother you, just saying. 08.52.40 # only that crazy dude on the forum 08.52.44 Quit tertu (Ping timeout: 268 seconds) 08.53.13 Join fs-bluebot [0] (~fs-bluebo@f053155084.adsl.alicedsl.de) 08.53.38 # <[Saint]> It really surprises me that pamaury chose to revert the stepping on the F+ rather than push g#519 08.53.40 # 3Gerrit review #519 at http://gerrit.rockbox.org/r/519 : 3Fix volume handling of steps in wps, list and radio by Amaury Pouly (changes/19/519/1) 08.53.45 # <[Saint]> huzzah! 08.54.34 # [Saint]: because that patch doesn't help the volume handling issue 08.55.09 # <[Saint]> It most certainly should. 08.55.25 # would it make the volume keys deal with 1dB steps? 08.55.56 # it looks like it only makes %pv display the correct value, doesn't it? 08.56.30 # are you confused about what I'm bitching about? 09.00.14 # <[Saint]> Possibly. So you're not ranting about the hilariously inaccurate dB values? 09.00.47 # No! 09.00.48 # geez 09.01.00 # where did you get that idea? 09.01.34 # hilariously inaccurate? that would explain why the volume steps appear to be much smaller at lower volumes :D 09.01.37 # nowhere do I mention that in either one of my ML posts 09.02.10 # * copper bangs his head against the wall 09.02.17 # <[Saint]> Yes, but you also mention things that aren't relevant...and you have mentioned the dB values being incorrect in the past. 09.03.17 # <[Saint]> I'm sure I'm not the only one that has soem difficulty trying to parse whatever the grievance de jour is. 09.03.38 Quit kevku (Ping timeout: 260 seconds) 09.03.44 # what did I mention that isn't relevant? 09.04.51 *** Saving seen data "./dancer.seen" 09.05.11 # my ML post mentions volume keys and the graphical equalizer, explicitely 09.05.33 # and argues that 0.1dB steps are not only inaudible, they also adversely affect usability 09.05.43 # what is not clear in there? 09.06.18 # presumably they're only inaudible at the bottom end of the scale, since, ya know, db is logarithmic 09.06.21 # http://www.rockbox.org/mail/archive/rockbox-dev-archive-2013-07/0013.shtml 09.06.34 # copper: chill out man - give him a chance to catch up 09.06.37 # GodEater: what? 09.07.01 # what do you mean by "bottom end of the scale"? Very low volumes? 09.07.03 # you're ranting without giving [Saint] another opportunity to parse what you wrote 09.07.08 # oh that 09.07.11 # yes - low volumes 09.07.18 # <[Saint]> .1 dB is like...what, ~3% total volume or so? 09.07.26 # <[Saint]> that _should_ be audible. 09.07.35 # wth 09.08.19 # copper: you come across as a very angry man. 09.08.20 # I don't even know what a percentage means in that context 09.08.39 # GodEater: I'm annoyed 09.08.47 # 1dB should be barely audible. at any volume 09.08.52 # people have been stonewalling me on this for what, 2 days? 09.09.01 # and yeah, ABX logs please 09.09.07 # 0.1dB audible? Come on. 09.09.28 # the db scale is logarithmic, but so is human hearing 09.10.09 # I'll eat my hat and post a youtube video of it if anyone successfully ABXes a 0.1dB difference at either end of the scale 09.10.56 # <[Saint]> I worded that badly. .1dB is about a 2~3% difference, it _should_ be audible... 09.11.09 # how do you figure that number? 09.11.18 # 3% of what 09.13.00 # <[Saint]> in apparent volume between it and the next or previous step. But how audible it is probably depends on how far down, or up, you are on the scale. 09.13.39 # <[Saint]> at very low volumes, it almost certainly wouldn't make a difference. Higher volumes...not so sure. 09.15.27 # I don't think percentages in this context mean anything 09.15.30 # what's 100%? 09.15.46 # 3dB? 6dB? 09.15.48 # +10db is twice as loud 09.16.09 # 6dB is 09.16.16 # no 09.16.26 # in the context of digital audio, it is 09.16.40 # you're not listening to digital audio 09.17.05 # 0.5 FS is -6.02dB 09.17.09 # 1 FS is 0dB 09.17.23 # 0.25 FS is -12.04dB 09.18.25 # that's not important to the user. he wants to know the difference in dB SPL 09.19.06 # <[Saint]> ZincAlloy: while you're here - how friendly are you with Inkscape/SVG? 09.19.14 # in any case, let's drop the percentages please 09.19.20 # I'm using it for some basic stuff 09.19.36 # <[Saint]> You ever fely like making some high-res cabbie masters? :) 09.19.40 # <[Saint]> *felt 09.19.55 # We do have rather high res cabbie masters 09.20.15 # <[Saint]> not in scalable vector, though. :) 09.20.16 # psd, though 09.20.35 # right. but do we need that? 09.21.14 # <[Saint]> I seem to recall the .psd files I managed to dig up being incomplete. Could be wrong. 09.21.35 # what was missing? touch screen icons? 09.22.02 # <[Saint]> yeah, the quickmenu stuff iirc. 09.22.49 # gotta put up a new one with the scan icon anyway 09.23.18 # http://trace.wisc.edu/docs/2004-About-dB/ 09.23.34 # * [Saint] has re-read, and re-read, and now feels as though he has a complete grasp on copper's concerns. 09.24.04 # <[Saint]> the apparent linking of EQ and volume stepping confuzzled the fuck out of me. 09.25.02 # you started it :P 09.27.20 Quit Strife89 (Quit: This computer has gone to sleep) 09.28.01 # ZincAlloy: +6dB is twice the voltage, +10dB is 3 times, and +12dB is 4 times 09.28.04 # [Saint]: The current graphics package contains all the touch screen icons, but not the fm icons 09.28.39 # yes, but +10dB is still percieved as twice as loud 09.29.03 # <[Saint]> Hmmmm. I was sure there was something missing. Sorry. 09.29.17 # <[Saint]> Perhaps whatever I was loking for was buried under some layer. 09.29.21 # <[Saint]> *looking 09.29.44 # what were you looking for? 09.31.01 # <[Saint]> I can't remember exactly now, but, it was on my ToDo list - so I need to assume it was /something/ 09.31.23 # http://www.rockbox.org/wiki/pub/Main/DefaultWPS/cabbie2graphics.zip 09.31.25 # <[Saint]> "ToDo: Talk to ZincAlloy about missing cabbie elements" 09.31.35 # I'll put up a new one later 09.31.45 # <[Saint]> I assume I wrote that (over 18 months ago (:P)) for a reason... 09.32.21 # and I should make png to use with other applications as well 09.33.37 # http://www.sengpielaudio.com/calculator-levelchange.htm 09.34.49 # that page, if I understand correctly, seems to suggest that a 6dB change in volume (double the voltage) is perceived as 10dB increase, which is also "double the perceived volume" 09.34.55 # it's confusing as hell 09.35.31 # yeah. translating units can be quite a pain 09.35.42 Join lorenzo92 [0] (~chatzilla@host4-107-dynamic.20-79-r.retail.telecomitalia.it) 09.36.34 # ZincAlloy: but that means that +6dB in Rockbox is indeed twice the perceived loudness 09.36.52 # +6dB in Rockbox = ratio of 2 = twice the voltage 09.36.56 # let me check.. 09.37.07 # s/ratio/factor/ 09.39.33 # er 09.39.45 # that page is very confusing 09.40.02 # it's not just that page 09.40.13 # it's the whole matter 09.41.57 # ah ha! "Actually, the just- noticeable-difference [in audio level] varies from0.1 dB to about 5 dB, depending on bandwidth, frequency, programmaterial, and the individual." 09.42.20 # while at the same time "One dB is the smallestchange in level that most people can hear--the just-noticeabledifference." 09.42.22 # <[Saint]> woo! I was partially right about something! 09.43.18 # "A 6 to10 dB increase in level is considered by most listeners to be"twice as loud." 09.43.20 # about what? 09.43.39 # about noticeable differences in level 09.43.57 # I meant [Saint] 09.44.01 # <[Saint]> about .1dB potentiality being audible 09.44.17 # ZincAlloy's quote says 1dB 09.44.25 # read again 09.44.35 # <[Saint]> "0.1 dB to about 5 dB" 09.45.01 # the two quotes contradict each other 09.45.01 # <[Saint]> massive range, but, I'll take it - it agrees with me :) 09.45.14 # <[Saint]> No, they don't. 09.45.26 # <[Saint]> /most/ people. 09.45.30 # <[Saint]> not *all* people. 09.46.28 # and the 1dB thing is a general statement. .1 to 5 depends on a lot of factors. On average you can expect 1dB steps to be barely audible 09.47.16 # <[Saint]> Yeah, this seems to depend on how high or low the volume is at the time it it increased or decreased by .1dB 09.47.36 # <[Saint]> *it is 09.49.33 # not sure how it relates to sound pressure. the text doesn't mention a corelation 09.50.16 # though the human hearing is the most linear at around 80dB SPL 09.53.13 Join kevku [0] (~kevku@2a01:d0:ffff:34a::8:3) 09.54.40 # what is it that rockbox is displaying? dBu? dBv? 09.59.49 # dBFS 10.00.06 Quit akaWolf (Ping timeout: 245 seconds) 10.00.07 # ah, right. of course. it's digital 10.00.13 # not even 10.00.22 # it's analog on targets that support it 10.07.13 # kugel: ping 10.07.49 # here are three 30 seconds samples of "Get Lucky" by Daft Punk: 10.07.52 # original: http://outpost.fr/stuff/getlucky-00dB.flac 10.08.02 # 0.1dB quieter: http://outpost.fr/stuff/getlucky-01dB.flac 10.08.07 # 0.5dB quieter: http://outpost.fr/stuff/getlucky-05dB.flac 10.08.40 # <[Saint]> Well holy shit...quassel is frickin' awesome. 10.08.48 # <[Saint]> hover-link plays those files :) 10.09.37 # <[Saint]> gah...the source can't keep up. 10.11.47 # not quite noticeable 10.12.11 # I have trouble ABXing the 0.5 dB difference, but I think it can be done 10.13.01 # does it make a useful difference though? Not really. 10.13.08 # never mind the 0.1dB difference 10.13.21 # too subtle a step to be useful for a mp3 payer volume control 10.13.25 # yes 10.14.00 # some pro audio EQs have stepped pots - with 0.5 or 1db steps 10.14.26 # <[Saint]> volume step? yes. EQ - still unsure. 10.15.17 # in some frequency bands changes are very easily noticeable 10.15.30 # <[Saint]> Yes, that's my point. 10.16.09 # kugel: or anyone else, can you give me some hint to copy the entire toolchain from a system to another? i.e. i compiled it in the virtual machine, but it would be better to run it on the host OS 10.16.09 # I'd be OK with 0.5dB steps in the EQ and 1dB steps for volume 10.16.23 # I think the EQ feels good as is 10.16.34 # ZincAlloy: with 0.1dB steps? 10.16.38 # 1dB 10.16.39 # <[Saint]> define "as is" 10.16.45 # ZincAlloy: it's currently 0.1dB 10.16.51 # <[Saint]> because "as is" == .1dB 10.16.54 # that would be too small 10.17.23 # lorenzo92: pong 10.17.36 # lorenzo92: actually, you asked me about the toolchain recently? it's still on my ftp 10.17.44 # 1dB steps are subtle enough imho 10.17.45 # <[Saint]> realistically, the EQ should present the stepping the hardware accepts. 10.17.52 # no 10.17.55 # kugel: ah! great :) 10.17.59 # <[Saint]> since it doesn't, the only way to not "lose out" is .1dB stepping 10.18.14 # what if the hardware presented 0.001dB steps 10.18.20 # would you want to reflect that in the UI? 10.18.31 # so as to "not lose out"? 10.18.41 # <[Saint]> seeing as the lowest I have ever seen is .2, I think we needn't worry there. 10.18.57 # my point is that usability and audibility trump hardware support 10.19.00 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.19.20 # <[Saint]> This only affects usability because the "fast EQ stepping" doesn't work. 10.19.26 # <[Saint]> It should. But, doesn't. 10.19.40 # what is that and how would I use it if it did work? 10.20.13 # <[Saint]> if you held down the button, instead of individual .1dB steps, it would do, say, 1dB steps. 10.20.26 # <[Saint]> much like accellerated scrolling in lists. 10.20.30 # that's a really good way to overshoot 10.20.31 # <[Saint]> eeek. spelling. 10.21.01 # I'd rather do it the other way round. 1dB steps unless a button is held down 10.21.13 # easier to use for the casual user 10.21.23 # <[Saint]> it would, in theory, be possible to do that, yes. 10.22.37 # [Saint]: btw, what does hardware support have to do with the EQ at all? 10.22.51 # isn't the EQ totally in software? 10.23.45 # you're not telling the hardware to lower a frequency band by the smallest amount that the hardware supports 10.23.50 # <[Saint]> Not in all cases, I don't think. Needs confirmation. 10.24.55 # internally, the hardware supports all volume variations, since it is converting a digital signal with 16 bit precision into an analog signal 10.25.06 # hardware volume steps have nothing to do with that 10.25.29 # the hardware does not care what Rockbox does to the signal, it's not involved 10.26.21 # even if the hardware supported only 6dB volume steps, Rockbox could still alter some frequency bands by 0.001dB, and the hardware would faithfully convert that signal into analog 10.26.42 Join froggymana [0] (~froggyman@unaffiliated/froggyman) 10.27.39 # so unless you're using a hardware EQ built into the DAC chip, which matches the Rockbox EQ configuration EXACTLY (with 10 bands), then the Rockbox EQ steps are completely unrelated to the hardware 10.28.08 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 10.28.22 # if the hardware EQ is 5 bands, then the Rockbox EQ is still software 10.28.26 Join JdGordon [0] (~jonno@CPE-121-217-4-18.lnse1.cht.bigpond.net.au) 10.28.27 Quit JdGordon (Changing host) 10.28.27 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 10.28.50 # I would be very surprised if there was ANY Rockbox port in which the EQ is not 100% software 10.28.51 Join akaWolf [0] (~akaWolf@188.134.9.161) 10.28.51 Quit akaWolf (Changing host) 10.28.51 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 10.29.09 # copper: what did you ABX on? 10.29.11 # so there's nothing to "lose out" 10.29.16 # maraz: foobar2000 10.29.25 # if rockbox displays dBFS values - why can there be positive values? 10.29.29 # <[Saint]> Hum. That's a good point. There's not really any point in my discussing this. I've lost count of the times I've stated I don't care a fuck about the stepping of the EQ by now. :) 10.29.40 # ZincAlloy: 2FS is a valid value 10.29.52 Quit froggyman (Ping timeout: 240 seconds) 10.29.52 Quit x56 (Ping timeout: 240 seconds) 10.29.53 Quit tchan (Ping timeout: 240 seconds) 10.29.53 Quit bluebrother^ (Ping timeout: 240 seconds) 10.29.57 Quit JdGordon_ (Ping timeout: 240 seconds) 10.29.59 Nick froggymana is now known as froggyman (~froggyman@unaffiliated/froggyman) 10.29.59 # I thought 0 was max for FS? 10.30.06 # it's not "max" 10.30.09 # it's the reference 10.30.22 # <[Saint]> 0 == reference 10.30.24 # copper: headphones or speakers? 10.30.27 # <[Saint]> dammit. 10.30.38 # +6dB (2FS) would badly clip the signal if it peaks at 0dBFS 10.30.42 Join x56 [0] (~0x56@sillytitties.com) 10.30.57 # but it will produce a perfectly valid signal with content that never goes past 0.5FS 10.31.02 # "0 dBFS is assigned to the maximum possible digital level." no? 10.31.14 # maraz: IEMs 10.31.25 # ah, that explains it. 10.31.31 # ZincAlloy: it's just a mathematical representation 10.31.32 # maraz: ? 10.31.53 # copper: I tried on my desktop multimedia speakers and don't find it too hard to abx 0.0 and -0.5 10.32.03 # ZincAlloy: 0.5FS = -6dB, 1FS = 0dB, 2FS = +6dB, etc… 10.32.32 # <[Saint]> maraz: wow, what type of speakers are those? I would assume that would make it a lot harder. 10.32.35 # maraz: I'm sorry but I have to ask, do you know what ABX means? 10.32.40 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 10.32.46 # copper: yes, I used the fb2k ABX comparator 10.32.51 # logs? 10.32.52 # probability that you were guessing: 3.5% 10.32.58 # not low enough 10.33.01 # true 10.33.01 # er 10.33.05 # never mind 10.33.09 # still, 7/8 :) 10.33.12 # I think I failed the first one 10.33.36 # <[Saint]> 7/8 is "verified". 10.33.40 # [Saint]: something I rigged up from a pair I had laying around. 10.33.41 # <[Saint]> now...repeat it! 10.33.50 # should I? 10.34.05 # <[Saint]> Nah. I don't care in the slightest ;) 10.34.06 # maraz: my IEMs didn't prevent me from ABXing 10.34.15 # just my sensitivity and concentration at the time 10.34.34 # <[Saint]> My assumption would be IEMs make this process a lot easier. 10.34.48 # I got like 4/6, and I stopped because I thought it could probably be ABXable 10.35.08 # so I'm not going to claim that a 0.5dB difference can't be ABXed 10.35.58 # but I still maintain that it's not useful, as far as volume control is concerned 10.36.09 # yeah, probably not. 10.36.25 # fwiw, I think 0.5 db would be a goog compromise 10.36.34 # however, it's easy to tell once you spot something that gives it away, like snare decay 10.36.49 # kugel: it would still make volume control twice slower 10.36.51 # kugel: so my idea is to patch R0's cramfs on the fly, by means of our patched cramfs that ONLY contains files to be put in the rom 10.37.12 # copper: we're talking about the eq which is currently 0.1 isnt it? 10.37.16 # kugel: i.e. without extracting the original cramfs, process that's painful in windows (cygwin etc) 10.37.23 # kugel: both the EQ and volume control 10.38.13 # though the volume control problem was only on the Fuze+ apparently, and pamaury reverted it recently 10.38.14 # bluebrother: i was talkin with kugel about YP-R0 and rbutil. Firmware packing and unpacking tools are ready but I'm still missing how to patch cramfs on windows... 10.38.46 # <[Saint]> I'd be cool with q == .1dB and EQ == .5dB, I'm given to understand there may be genuine reasons why someone might want that fine control there. 10.38.53 # normal volume control is, and has ever been, in 1db steps, no? 10.39.04 # <[Saint]> Not anymore, apparently. 10.39.11 # <[Saint]> see dev-ML 10.39.17 # * kugel must have missed something 10.39.56 # <[Saint]> kugel: http://www.rockbox.org/mail/archive/rockbox-dev-archive-2013-07/0002.shtml 10.40.51 # he said the internal representation changed, but what about the UI? 10.41.04 # <[Saint]> g#519 10.41.06 # 3Gerrit review #519 at http://gerrit.rockbox.org/r/519 : 3Fix volume handling of steps in wps, list and radio by Amaury Pouly (changes/19/519/1) 10.42.07 # how's this specific to the fuze+? 10.42.35 # kugel: because only pamaury started adapting the change to volume control 10.43.01 # btw, the semi consensus that we got here is 1dB for volume and 0.5dB for EQ… which is precisely the way it was before the change! 10.43.19 # <[Saint]> and then very recently reverted it, due to the shit-storm it created, and fear of people thinking he caused it. 10.43.23 # copper: sounds good to me as well 10.44.15 # copper: indeed, I don't find any reason to complicate things up 10.44.25 # aaaaaah 10.44.25 # I'd have no problem with 0.5dB for EQ, but I think 1dB will do just fine 10.44.31 # * copper sighs in relief 10.44.53 Quit akaWolf (Ping timeout: 246 seconds) 10.45.08 # another argument is that users might have to deal with much larger ranges in volume (when changing headphones, or when using it as a line out) than they would in the EQ 10.45.30 # so 0.5dB steps are much less problematic, usability-wise, in the EQ, than they are in volume control 10.46.08 # e.g a user could use Rockbox at -32dB with their highly sensitive IEMs, and then set it to 0dB when plugging into a hi-fi or a car stereo 10.46.29 # <[Saint]> as long as if/when EQ goes back to .5dB, q stays at .1dB. 10.46.31 # that would be 320 steps of 0.1dB, 64 steps at 0.5dB 10.46.38 # db display in the eq is weird 10.46.38 # [Saint]: what's q? 10.46.49 # <[Saint]> I'm willing to be proven wrong, but I'm given to believe there's a genuine use for the latter. 10.46.54 # 0dB and −0db? 10.48.16 # <[Saint]> copper: http://en.wikipedia.org/wiki/Q_factor 10.48.44 # that's mandarin to me 10.49.26 # <[Saint]> higher q, the less it bleeds into the ranges beside it, and vice versa. 10.49.41 # <[Saint]> high q, sharp peak, low q, wide peak. 10.49.51 # similar to bandwidth 10.50.27 # ah 10.50.33 # that's the thingy that I don't use 10.50.55 # <[Saint]> virtually no one does, as you need to be a rocket scientist to do it on-the-fly 10.51.18 # <[Saint]> a nice graph to plot the EQ has been discussed a few times. 10.51.26 # brb 10.51.47 # I was wrong about the eq on my fuze being in 1dB steps 10.51.56 # clip zip, not fuse, sorry 10.52.04 # * pamaury doesn't want to be killed by the crowd but still think there is a massive misunderstanding about what happened, nevermind. Could I also remind people that nightly builds are not subject to same quality requirements as releases ? 10.52.07 # it's 0.5, but only displays full dBs 10.52.08 # copper: if you frequently do that sort of range and find the stepping annoying, use the shortcut menu and 2 configs 10.52.45 # pamaury: absolutely ! 10.52.46 # JdGordon: wrt volume control? 10.52.56 # <[Saint]> pamaury: by all means, if you want to speak, speak - a precise breakdown of what happened, and why, is welcomed. 10.53.32 # <[Saint]> both you and I have taken blame for this (though, I brought it on myself assuming I was responsible), so, go nuts. :) 10.53.56 # copper: yes 10.54.37 # JdGordon: I'll look into that, thanks. But my point about usability, audibility and usefulness remains 10.55.25 # I already explained too many times: the volume never was, never will be, never fucking is in 0.1dB steps, this is a UI bug. I'm pretty sure it's the same for EQ. People keep arguing about 0.5dB vs 0.1dB vs 1dB but the truth is that the change probably never intended to change it. 10.58.00 # pamaury: where is the UI step defined? 10.58.28 # is it defined at all, with regards to "internal" 0.1dB steps? 10.58.34 # is there a provision for that? 10.58.57 # some code that says somewhere, the UI should always deal with 1dB steps, no matter the internal base value 11.00.43 # JdGordon: can I load a .cfg file with a "file" type shortcut? 11.00.56 # type: file 11.01.06 # data: /.rockbox/some.cfg 11.01.07 # ? 11.01.42 # that's the point: the code just increases the volume, and don't care about its unit. The unit depends on the target, it might 1dB or 0.1dB. And it completely ignores hardware steps. 11.04.55 *** Saving seen data "./dancer.seen" 11.09.01 # JdGordon: wow, that makes my Fuze+ crash, hard 11.09.11 # "data abort at [etc]" 11.10.58 # it also makes the sim crash 11.11.18 # Segmentation fault (core dumped) 11.12.17 # brb 11.13.52 Join ukleinek [0] (~ukl@unaffiliated/ukleinek) 11.40.45 # lorenzo92: how would that work? 11.41.03 # cramfs is compressed isnt it? 11.41.56 # exactly. I tought about modifiying the mkcramfs executable to read the original cramfs and at the same time another small cramfs that ONLY contains needed modifications (files) 11.42.15 # kugel: and then producing a new cramfs with both mixed in 11.42.45 # in this way we completely avoid the problem of attributes, filenames while extracting 11.43.47 Quit [Saint] (Quit: something is a sick puppy here...) 11.52.15 Join [Saint] [0] (~saint@rockbox/user/saint) 11.53.37 Join krabador [0] (~krabador_@unaffiliated/krabador) 11.57.36 # goddamn 11.57.56 # when rockbox saves the configuration to config.cfg, it ommits default values 11.58.20 # so when you load another config file with non default values, and then revert to the first config file, non-default values from the second config file remain 11.58.54 # This is on purpose. If you save a config explicitly, it will contain all values 12.00.44 # very trivial patch here g#321, can someone check it? 12.00.46 # 3Gerrit review #321 at http://gerrit.rockbox.org/r/321 : 3Cube plugin fix by Lorenzo Miori (changes/21/321/2) 12.01.39 # well wait now that i see there is also the atextit() function!! what the hell? 12.02.52 # lorenzo92: the patch isnt trivial at all :p exit() is supposed to work for plugins 12.03.01 # it works in the sim doesnt it? 12.03.29 # exit() is provided by plugin_crt0.c, thus plugins should *not* be able call the libc version 12.03.31 # kugel: ah! okay then there is another problem :) the point is that I did not find any other plugin using the exit(), so I assumed there was a problem 12.03.58 # frotz uses exit(), no? 12.04.01 # most call exit_on_usb() which is a small wrapper 12.04.21 # pretty sure i added the proper exit support for that :) 12.04.30 # or fixed it. or sometbing. 12.04.35 # <[Saint]> Torne: frotz probably isn't very high on the list of commonly tested plugins :) 12.05.07 # let me check 12.06.03 # interesting, frotzt is even *not* compiled on R0 lol 12.07.52 Nick uwe__ is now known as uwe_ (~uwe_@dslb-088-064-049-075.pools.arcor-ip.net) 12.10.15 # I can't use this thing 12.10.46 # <[Saint]> "this thing"? 12.11.30 # kugel: there there must be a problem with longjmp 12.22.43 # kugel: actually, commenting out the exit function does the same (either crash or real exit) hum 12.22.58 # in plugin_crt0 of course 12.33.47 # how important is ipod classic dualboot to us? 12.34.06 # anyone willing to actually take care of getting that fixed? 12.36.08 # Torne: I think I did it :) 12.37.04 # lorenzo92: well, plugin_crt0's exit has to be called 12.37.20 # ah, i added atexit() support :) 12.37.38 # not-quite-atexit support 12.37.46 # but you fixed a bunch of things :) 12.38.06 # kugel: then I don't understand....commenting out longjmp still crashes/closes 12.38.13 # brb 12.46.49 # so I guess not very important... 12.50.27 # <[Saint]> willing != able 12.51.09 # <[Saint]> those that want it don't have the time or technical ability, evidently. 12.51.48 # <[Saint]> its no blocker for the ports sake, ...qoukd it be handy? yep. 12.52.10 # <[Saint]> could I do it? ability - maybe, time - nope. 12.52.23 # roughly same here 12.54.29 # TheSeven: isn't Rockbox Util support the top priority? 12.54.50 # and a stripped down bootloader 12.58.12 # <[Saint]> I wasn't sure anyone mentioned priority. 13.00.05 Join akaWolf [0] (~akaWolf@188.134.9.161) 13.00.05 Quit akaWolf (Changing host) 13.00.05 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 13.00.50 Join mortalis [0] (~mortalis@118.34.139.222) 13.03.47 # * copper finally managed to make 4 proper config files for his Classic and Fuze+ 13.04.59 *** Saving seen data "./dancer.seen" 13.05.48 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 13.07.31 Join olspookishmagus [0] (~pookie@91.132.63.143) 13.27.04 Quit belak (Quit: belak) 13.30.09 # copper: well, what's the way to go there? 13.30.17 # what does it take? 13.30.41 # can we teach the rockbox utility to talk to DFU devices on windows? 13.30.44 # can it install drivers? 13.31.08 # o_O 13.31.11 # what do I know 13.31.15 # should we go for a completely different approach? 13.31.25 # get the notes exploit to work on the classic and install through that? 13.31.56 # are you actually asking ME? 13.32.01 # <[Saint]> that would be desirable. 13.32.07 # I'm asking the channel... 13.32.18 # <[Saint]> re: noteboot 13.32.32 # ok, what are the dependencies of that? 13.32.35 # <[Saint]> it'd be a lot easier for the user at least. 13.33.02 # * [Saint] prods bluebrother 13.33.08 # <[Saint]> ^ 13.33.21 # 1. OF version dependent return address 13.33.21 # 2. we need to be able to read files from the HDD in ~3 kilobytes of code 13.33.32 # 3. we need to figure out that return address 13.33.51 # OF hasn't been updated in years 13.33.52 # 4. the firmware must be vulnerable to it in the first place, and people might need to downgrade 13.34.14 # IIRC the latest firmware has already patched that vulnerability 13.37.46 # why downgrade? emCORE works with the latest OF 13.53.11 # [Saint]: Graphic package updated 13.56.12 Quit kevku (Ping timeout: 245 seconds) 13.58.03 Quit liar (Read error: Connection reset by peer) 14.00.59 # http://www.felixbruns.de/iPod/firmware/ 14.23.47 Join amayer [0] (~amayer@mail.weberadvertising.com) 14.50.17 # This forum thread is weird: http://forums.rockbox.org/index.php?topic=35372.msg220041;topicseen#new <- bots i'm guessing? 14.53.19 Quit lorenzo92 (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130712032019]) 14.54.21 # Hmm, indeed 14.55.44 # * gevaerts decides to delete the lot 14.56.13 # Not sure if banning makes sense 14.57.31 # All of those accounts have been used exactly once 14.57.37 # * gevaerts decides not to bother 15.04.49 # copper: currently emcore doesn't work with any OF version, but if we want to install through the notes exploit we need a vulnerable firmware, and the latest one is fixed 15.05.01 *** Saving seen data "./dancer.seen" 15.06.30 # so we have 3 possible "attack vectors" to install our firmware: 15.06.51 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 15.07.43 # 1. pwnage 2.0 exploit in DFU (which is what emcore currently does) 15.07.43 # 2. pwnage 2.0 exploit in on-disk firmware (requires an old bootloader version, which IIUC only works on 1g models) 15.07.43 # 3. notes exploit within the main firmware (requires a specific exploit for each firmware version, the latest firmware is fixed so it doesn't work) 15.10.08 # DFU is certainly the most robust, surefire way of booting this thing (apple can't possibly patch it), but it has two problems: 15.10.08 # 1. it requires the user to press buttons for precise amounts of time (many users fail to do that right, even though it is fairly easy, if you just follow the instructions literally) 15.10.08 # 2. on windows it requires a special driver for the DFU mode to be installed, which will interfere with itunes. it can also piggyback on itunes' driver, but then that has to be installed and itunes will interfere with the DFU boot process if you don't kill each and every apple process at the right time 15.10.51 # the pwnage in on-disk firmware exploit is not practical IMO because it will only work on 80gb and 160gb thick models which have never been updated 15.11.02 # the notes exploit could be an alternative 15.19.02 Join pretty_function [0] (~sigBART@123.252.212.122) 15.20.39 # <[Saint]> the only way they could really attempt to stop noteboot is if they released a new firmware which disallowed flashing an older version, and people updated. 15.21.05 Quit mortalis (Quit: Leaving) 15.21.27 # <[Saint]> its pretty safe to say they've stopped with updates to the current Classic line, though. 15.22.33 Join mortalis [0] (~mortalis@118.34.139.222) 15.30.32 Quit pretty_function (Remote host closed the connection) 15.44.35 Quit krabador (Quit: Sto andando via) 16.04.49 Quit mortalis (Quit: Leaving) 16.05.08 # so you'd let the rockbox utility downgrade the firmware and install through noteboot? 16.12.07 Quit shamus (Read error: Connection reset by peer) 16.12.45 Join shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net) 16.20.27 # <[Saint]> presumably. but that seems messy. 16.23.57 Quit [Saint] (Remote host closed the connection) 16.24.27 Join tertu [0] (~tertu@65-128-181-81.mpls.qwest.net) 16.24.54 Join [Saint] [0] (~saint@rockbox/user/saint) 16.36.52 # it does indeed. 16.37.11 # the question is if DFU is more or less messy. or if there's another route that I'm missing. 16.48.26 Join Scall [0] (~chat@unaffiliated/scall) 16.49.40 # <[Saint]> there's no route I'm aware of that you didn't cover. 16.51.25 # <[Saint]> the DFU method is super ugly on Windows, and oh so painless with Linux...that bugs me. 16.52.20 # <[Saint]> well, the "+iTunes" method is. 17.04.18 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 17.04.22 Join Strife89 [0] (~Strife89@2602:306:250e:c3c9:20a:95ff:fef3:ec5f) 17.05.05 *** Saving seen data "./dancer.seen" 17.11.00 Quit melmothX (Quit: ciao) 17.19.56 Quit GeekShadow (Read error: Connection reset by peer) 17.20.16 Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 17.20.22 Join GeekShadow [0] (~antoine@reactos/tester/GeekShadow) 17.22.18 Quit Strife89 (Quit: Vamoose!) 17.22.22 Join Strife1989 [0] (~Strife89@2602:306:250e:c3c9:f592:5f13:5b75:3336) 17.23.22 Join guymann [0] (~c@unaffiliated/guymann) 17.30.58 Quit benedikt93 (Quit: Bye ;)) 17.49.27 Quit olspookishmagus (Read error: Operation timed out) 17.50.31 # [Saint]: the non-itunes method is outright broken afaict 17.51.28 Join olspookishmagus [0] (~pookie@91.132.63.143) 17.51.51 Nick olspookishmagus is now known as Guest15077 (~pookie@91.132.63.143) 17.59.11 # TheSeven: I've never been able to put the iPod in DFU mode on Windows 17.59.20 # with and without iTunes and other apple stuff installed 17.59.31 # it always fails on my install 18.05.07 # lebellium: if you would build the bootloader yourself from source you should get a dualboot bootloader 18.05.20 # for the Iaudio X5 that is 18.09.19 # pixelma: you mean it won't work with RButility? 18.10.58 # i'm ok with just having rbutil tell the user to put the device in DFU mode 18.11.08 # it looks like no updated bootloaders were released back then - the available bootloaders on download.rockbox.org (which the Rockbox Utility uses) and in the wiki are from 2008 and the dualboot patch got committed in 2011 18.11.52 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 18.12.32 # pixelma: ok sounds clear, thanks. I hope it's not too hard to build my own bootloader, I'll look at it 18.12.58 # or give amiconn a nudge to test and release newer ones ;) 18.13.24 # he doesn't look active enough for that :) 18.14.01 # That's because he doesn't get enough nudges :) 18.14.12 # if you already set up the environment then building the bootloader isn't hard, it's just an option in configure 18.14.14 # Anyway, no, building a bootloader is not hard 18.14.34 # It's just the same as building a regular build, except you pick "b" in configure 18.15.05 # ok nice, so it should be easy then, I already have my environnement 18.15.05 # and for the Iaudios testing and installing bootloaders is safe as the Cowon loader still will be there and takes care of the flashing 18.15.51 # quite safe I mean, don't want to sound a 100% sure 18.16.16 # the dualboot patch in 2011 was only for X5 right? 18.17.01 # copper apparently you have to make sure iTunesHelper isn't running for it to enter DFU mode properly 18.17.31 # tertu: I've tried everything 18.17.42 # I don't know, maybe my Win7 install is fucked up 18.17.54 # the iPod acts right, i assume 18.17.56 # no problem on my Linux install 18.18.07 # reboots and then goes black? 18.18.29 # I also can't get iTunes to restore the OF on Win7 18.18.37 # I always need to borrow someone's Mac to do it 18.18.52 # lebellium: it was at least for the X5 and the M5, I'm not sure if it also applied to the M3. I'm running one on my M5 which doesn't help me much because the OF freezes hard with the SSD I have (weirdly but luckily the Cowon loader deals with it just fine though) 18.19.25 # that's a bit bizarre... i've only had problems like that dealing with an HFS iPod 18.20.46 # can the installer just kill any itunes processes itself? 18.21.01 # pixelma: how can I find this patch? (I won't use the OF much either, it's just that as a collector I need non-modded devices that work as they did originally. So I have to be able to show someone how was the OF back to 2005 :) ) 18.21.58 # it's committed, no separate patch anymore. You only need a new enough checkout of the source 18.22.49 # tertu: actually after I restore the iPod on a Mac, I then connect it to my Win7 install, and THEN iTunes finally tells me it wants to format it for Windows 18.23.08 # what kind of iPod are you using 18.23.13 # though I think I'm done restoring the iPod 18.23.26 # I got Rockbox on the Classic to finally work well 18.23.29 # iPod Classic 18.23.35 # last version 18.23.55 # pixelma: found :) http://git.rockbox.org/?p=rockbox.git;a=commit;h=91ce4b2a60c4cbe8e3568f79c3a73572461ff40d so apparently it's only for X5/M5, not M3 unfortunately. 18.24.55 # i have an 80GB classic and after I restored it on a Mac (the data partition got screwed up I think) basically everything worked from there first try 18.25.21 # lebellium: hmm, interesting. I didn't remember the define but I was better than amiconn himself who didn't remember that commit at all 18.27.07 # so it looks like there is a bit more to it to get the dualboot bootloader but I'm not sure I understand the commit message completely 18.28.04 # I'm not sure either :D I'll see that when charging is complete. A friend gifted me this X5, he hasn't used it for years so I don't know how's the battery now 18.30.21 # * pixelma thinks there's a high probability that the battery isn't in a good shape anymore, the Iaudio batteries seem to degenerate quite a bit with time 18.32.59 # he already replaced the battery once so that's not the original 2005 battery but that was in 2008 or something like that, already 5 years ago :S 18.36.28 Join belak [0] (~belak@facebook/engineering/belak) 18.37.24 Join krabador [0] (~krabador_@unaffiliated/krabador) 18.44.20 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 18.54.59 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 19.02.40 # * bluebrother wonders why lorenzo92 only shows up when he's at work :/ 19.03.01 # lorenzo92 (logs): is there a patch around? How does this patching work on Linux? 19.05.09 *** Saving seen data "./dancer.seen" 19.15.34 Join dell [0] (~dell@ool-435622d3.dyn.optonline.net) 19.16.10 Quit tertu (Ping timeout: 240 seconds) 19.19.15 Quit amiconn (Read error: Operation timed out) 19.19.17 Quit TheSeven (Read error: Connection reset by peer) 19.19.42 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 19.19.45 Join amiconn [0] (amiconn@rockbox/developer/amiconn) 19.32.00 Quit dell (Quit: Ex-Chat) 19.33.05 Quit bzed (Remote host closed the connection) 19.33.13 Join bzed [0] (~bzed@devel.recluse.de) 19.35.33 # I managed to build a normal X5 bootloader but I don't understand the instructions for dualboot here: http://git.rockbox.org/?p=rockbox.git;a=commit;h=91ce4b2a60c4cbe8e3568f79c3a73572461ff40d 19.38.45 # lebellium: first add that define somewhere (maybe in config/iaudiox5.h), then just build (i.e. run make) 19.38.55 # Then find the OF's x5_fw.bin 19.39.55 # And then, run ../../tools/mkboot -iax5 of_x5_fw.bin bootloader.bin output.bin 19.40.06 # (assuming you named the OF's file of_x5_fw.bin) 19.40.35 # Then output.bin should be the file you need. I don't know if that has to be named x5_fw.bin, but I wouldn't be surprised 19.40.53 # Just make sure you don't get all the .bin files mixed up :) 19.47.02 Quit Gareth (Ping timeout: 245 seconds) 19.47.22 # Strife1989: does /home/michael/android/sdk/build-tools/android-4.2.2 exist? 19.48.31 # What does ls -l /home/michael/android/sdk/build-tools/android-4.2.2/aapt say? 19.49.03 Join lorenzo92 [0] (~chatzilla@host150-107-dynamic.17-79-r.retail.telecomitalia.it) 19.49.55 # bluebrother: haha here I am ^^ well it's pretty simple: firmware gets unpacked, then the cramfs is extracted and patched (simply copying some files to the rootfs) and then the cramfs is again packed and so on 19.50.22 # gevaerts: -rwxrwx--- 1 michael michael 1122758 May 13 12:31 /home/michael/android/sdk/build-tools/android-4.2.2/aapt 19.50.27 # [19:38] gevaerts Then find the OF's x5_fw.bin > what do you mean here? I have to put the OF file in my build directory? 19.50.40 # lebellium: yes 19.50.58 # to say, in linux we can extract it without any problem, on windows, well...only cygwin quite solves the problem (quite, because I should modify the binary anyways to handle \\ characters) 19.51.12 # *in filenames 19.51.35 Quit bzed (Remote host closed the connection) 19.51.44 # bluebrother: so the solution I was thinking is to create a cramfs patcher, as described in previous messages 19.51.59 Join bzed [0] (~bzed@devel.recluse.de) 19.54.54 # gevaerts: ../../tools/mkboot: No such file or directory 19.55.27 # lebellium: well, possibly ../tools/mkboot. Depends on your directory structure, i.e. where your build directory sits 19.55.42 # I'm in rockbox/X5bootloader 19.56.03 # Just a single .. then 19.56.33 # * gevaerts assumed a build/target structure, which is what he uses himself these days 19.56.45 # Hmmm 19.57.20 # Strife1989: does running "/home/michael/android/sdk/build-tools/android-4.2.2/aapt" on its own do anything? 19.57.57 # "No such file or directory." :o 19.58.36 # OK. This is going to be a library/arch issue 19.58.49 # What does "file /home/michael/android/sdk/build-tools/android-4.2.2/aapt" say? 19.59.00 Join Gareth [0] (~gareth@2607:ff38:2:83::3) 19.59.05 # gevaerts: aapt: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped 19.59.19 # OK, do you have a 32 bit or a 64 bit system? 19.59.20 # I'm on 64-bit Ubuntu 13.04 19.59.24 # right 19.59.46 # gevaerts: so the of_x5_fw.bin I put in the directory has been modified now and is the file I have to put on the X5 (after maybe renaming it to x5_fw.bin) ? 19.59.46 # What does "ldd /home/michael/android/sdk/build-tools/android-4.2.2/aapt" say? 20.00.07 # "Not a dynamic executable." 20.00.32 # lebellium: the file itself shouldn't be modified, unless you specified it as an output file too, IIUC 20.01.07 # so I don't understand what ../tools/mkboot -iax5 of_x5_fw.bin bootloader.bin output.bin did? 20.01.47 # lebellium: do you now have a file named output.bin? 20.02.12 # yes. That's the one I have to rename to x5_fw.bin and put onto the X5? 20.02.16 # Yes 20.02.29 # Strife1989: you seem to have a rather pure 64 bit system then :) Let me have a look... 20.02.29 # ok now it's clear 20.02.31 # thanks :) 20.05.15 # Strife1989: do you mind taking this to PM? getting multiarch to work is a bit off-topic here I'd say 20.05.29 # gevaerts: That's fine. 20.06.13 Join einhirn [0] (Miranda@bsod.vpn.tu-clausthal.de) 20.07.34 Quit FOAD (Quit: I'll be back) 20.07.49 Join FOAD [0] (~foad@unaffiliated/foad) 20.11.55 Join dell [0] (~dell@ool-435622d3.dyn.optonline.net) 20.22.52 Quit einhirn (Ping timeout: 264 seconds) 20.28.21 Quit lorenzo92 (Ping timeout: 256 seconds) 20.35.24 Quit dell (Write error: Broken pipe) 20.42.49 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) 20.43.36 Join dell [0] (~dell@ool-435622d3.dyn.optonline.net) 20.56.02 Quit dell (Quit: Ex-Chat) 20.58.01 Join wodz [0] (~wodz@178.182.149.74.nat.umts.dynamic.t-mobile.pl) 21.01.47 Quit Guest15077 (Quit: All for nothing) 21.04.24 # gevaerts: hum firmware upgraded but it still boots the OF. It did not work 21.05.08 # lebellium: triple-check if all the .bin files are what you think they are 21.05.12 *** Saving seen data "./dancer.seen" 21.07.11 # I have of_x5_fw.bin (OF 2.10 I downloaded on the cowon website), x5_fw.bin automatically created when building and output.bin. I used output.bin (and renamed it to x5_fw.bin once on device) 21.09.11 Join EstebanMonge [0] (~emonge@200.110.251.210) 21.13.13 # lebellium: what exact command did you run to make the new output.bin? 21.13.45 # ../tools/mkboot -iax5 of_x5_fw.bin bootloader.bin output.bin 21.14.03 # * gevaerts nods 21.14.08 Join rockbox [0] (~androirc@host150-107-dynamic.17-79-r.retail.telecomitalia.it) 21.14.28 # I don't know then 21.15.57 # aaaaah 21.16.01 # now it works 21.16.25 # I just needed to plug it to the PC and unplug it after upgrading the firmware 21.16.33 # I don't understand why but at least it works 21.17.00 Quit thegeek (Read error: Connection reset by peer) 21.19.29 # * gevaerts also tries 21.21.00 # Worked the first time for me, but then I had the pure rockbox bootloader installed before. Maybe that makes a difference 21.21.49 Quit rockbox (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )) 21.22.02 # well that's not a big deal. It's just strange than directly after installing the new firmware it still booted the OF as if it had the previous bootloder/firmware still in cache 21.22.07 # that* 21.22.32 # * gevaerts needs to take his x5 apart to clean it and try to make the joystick a bit more responsive 21.22.41 # Maybe also new batteries... 21.24.34 # unfortunately the battery is soldered 21.29.43 # Yes 21.30.05 # But a dead battery is no better than a badly soldered new battery 21.31.10 # gevaerts: what about debugging h300 bootloader through BDM? 21.31.25 # * gevaerts needs to get back to that... 21.32.03 # wodz: devcon is probably the best bet to make serious progress there 21.32.44 # I'll be rather busy for the next month or so as well, so I'm unlikely to have much time before then anyway 21.33.03 # oh, and by the way are we fixed with 14-15 Sep for DevCon? 21.33.14 # Yes, as far as I know 21.33.29 # We'll need to find hotels though 21.34.43 # right 21.47.32 Join lorenzo92 [0] (~chatzilla@host150-107-dynamic.17-79-r.retail.telecomitalia.it) 21.49.18 Join melmothX [0] (~melmoth@unaffiliated/melmothx) 22.00.35 Quit pamaury (Quit: No Ping reply in 180 seconds.) 22.00.46 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 22.06.05 # pamaury: ping 22.07.27 Quit Marex (Ping timeout: 248 seconds) 22.07.40 Join Marex [0] (~Marex@195.140.253.167) 22.10.33 # lorenzo92: how are you manipulating the cramfs? Using mkcramfs from the cramfs package at sf? 22.12.27 # bluebrother: yes, exactly 22.12.35 # the problem arises on windows 22.13.00 # hmm. That doesn't immediately compile on windows 22.13.09 # so it needs some porting I guess ... 22.15.08 # exactly...and moreover we cannot do any extraction (permissions...filenames...) 22.15.56 # what kind of attributes does cramfs handle? 22.16.12 # everything (owner, group, etc) 22.16.13 # same as Linux? 22.16.17 # yes 22.16.26 # it's a linux rootfs :) 22.16.36 # back in 10 mins 22.17.15 # is it normal for my ipod class to basically require a total boot up when I lock the device when it isn't playing? 22.18.14 # micah: it turns off after some time of inactivity, so basically yes 22.18.44 # micah: rockbox doesn't enter deep sleep as OF does 22.18.53 Quit melmothX (Quit: #) 22.19.37 # and we want to replace some files inside the cramfs image, right? 22.25.46 # wodz: ok, i guess that can be configured too 22.26.40 # micah: idle time is configurable AFAIK 22.29.59 # ok cool 22.31.39 Quit y4n (Quit: AMIGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAHAHAHAAAAAAAAAAAAHAHAAA) 22.32.20 # <[Saint]> copper: that's....outright odd. 22.32.41 # bluebrother: yes, exactly 22.33.02 # <[Saint]> Are you sure you didn't confuse "not in DFU mode" with "actually in DFU mode, which is identical to "off" to the user without OF feedback"? 22.33.09 # <[Saint]> s/OF/OS/ 22.34.09 # "The display of your iPod should now stay black, and a new USB device called "Apple Recovery (DFU) USB Driver" should connect to your PC." 22.34.11 # <[Saint]> My understand is that "USB+hardware defined key-combo==can't possibly not enter DFU mode without hardware failure" 22.34.19 # bluebrother: so my idea was either to develop an "on-the-fly" patcher (i.e. I take content of one image an merge with another) or ...? 22.34.20 # the display is black but Win7 doesn't register 22.34.28 # "driver installation" fails 22.34.39 # <[Saint]> so, yes, its in DFU mode...but your OS is being a dick. 22.34.39 # yeah sorry 22.34.44 # <[Saint]> that's quite different. 22.34.46 # yes 22.35.20 # <[Saint]> I just had to check that one, because actually not going into DFU mode would be remarkable. 22.36.27 # <[Saint]> Its so sad that the WIndows install is *so* painful, and the linux install is entirely painless, but users assume it isn't...'cos linux. 22.39.17 # lorenzo92: the format doesn't seem to be too complicated as far as I can tell right now 22.39.30 # haven't found a detailed format description yet though 22.41.15 # lorenzo92: do you have a link to an example file we would be processing later? 22.41.36 Quit shamus (Ping timeout: 240 seconds) 22.44.00 # bluebrother: yeah the format isn't too cryptic ^^ 22.45.22 # so I guess it shouldn't be too much work to write some cramfs patching tool 22.45.34 # especially if it's just replacing files 22.45.51 # it's also about adding something... 22.46.03 # so the only thing we need to change in the inode structure is length / offsets 22.46.15 # hmm. Ok, then it will be a bit more work :) 22.46.20 # yeah :) 22.46.33 # eventually we could merge 2 images as I proposed... 22.46.34 # but the format itself doesn't look like something that is likely to give problems. 22.46.52 # would that make things easier? 22.46.57 # so that we keep inode structures 22.47.01 # I think so 22.47.13 # no permissions to handle on different OSes 22.47.36 # and we can keep our cramfs in the repo (no legal issues) 22.48.06 # what exactly are we doing to the image? Add a file and replace another one? 22.48.46 # replace a file and adding several ones (at least 2 + folder atm) 22.49.02 # but I'm planning to update the safe mode, so there will be 3 files or so 22.49.13 # ok, so we need to handle folders as well :/ 22.49.48 # * ZincAlloy just tried a much darker gradient for cabbiev2 for clip zip. no luck. looks just as shitty. the darkest shade of grey is just much too light compared with black. 22.50.44 # bluebrother: well, if that is a problem we may start in a more simple way avoiding that 22.50.55 # i.e. placing files in etc/ for example 22.51.03 Quit thomasjfox (Quit: Konversation terminated!) 22.52.12 # bluebrother: I just remind you about these tools g#506 ... they will be the first step in patching the firmware 22.52.14 # 3Gerrit review #506 at http://gerrit.rockbox.org/r/506 : 3Firmware tools for Samsung YP-R0/YP-R1 (and possibly others) by Lorenzo Miori (changes/06/506/6) 22.52.41 # they *should* work also on windows, I have only used ansi c standard lib 22.53.30 # <[Saint]> Hmmmmmm, odd. 22.53.56 # <[Saint]> Something is making 'sync" hang on my machine with an iPod Color plugged in using Rockbox USB. 22.54.03 # <[Saint]> ...doesn't happen in disk-mode. 22.54.11 # <[Saint]> Odd. 22.54.14 # <[Saint]> Odd odd odd. 22.54.54 Join rockbox [0] (~androirc@5.77.92.30) 22.55.46 # hmm, openssl 22.56.05 # that's not really a nice dependency on Windows :/ 22.56.13 # well, a native Windows build setup that it :) 22.56.15 # *is 22.56.18 Quit rockbox (Remote host closed the connection) 22.56.34 Join rockbox [0] (~androirc@5.77.92.30) 22.56.39 Quit rockbox (Remote host closed the connection) 22.56.52 Join rockbox [0] (~androirc@5.77.92.30) 22.57.20 # bluebrother: connection problems pff 22.59.05 Quit lorenzo92 (Ping timeout: 256 seconds) 22.59.18 Quit rockbox (Remote host closed the connection) 22.59.46 Join lorenzo92 [0] (~chatzilla@host150-107-dynamic.17-79-r.retail.telecomitalia.it) 23.00.02 # bluebrother: back online 23.00.46 # we can get rid of openssl -> it's just used for md5 computation 23.00.58 Part micah 23.01.06 # i think there is an implementation somewhere for it in rb, right? 23.01.16 # <[Saint]> yep. 23.01.41 # <[Saint]> hum, not sure if its in-core or a plugin, though. 23.01.42 Quit amayer (Quit: Leaving) 23.01.43 # ah, right. 23.01.47 # a plugin 23.01.55 # but I don't think that matters much :) 23.02.11 # just make it some libmd5sum, then use it from ypr0tools 23.02.51 # <[Saint]> many users accidentally find that plugin and complain. 23.03.00 # <[Saint]> but I don't recall it happening recently. 23.03.06 # <[Saint]> Its amusing when it does happen. 23.03.20 # <[Saint]> "My player is doing...things! Oh noes!" 23.03.56 # might be related to users using their phones these days instead? 23.04.38 # <[Saint]> I think that directly relates to marketing, and what is "cool". 23.04.52 # <[Saint]> Dedicated DAPs are largely dead. 23.05.14 *** Saving seen data "./dancer.seen" 23.05.23 # well, they are yet-another-pice-of-hardware to carry around 23.05.34 # and given that phones have enough capabilities these days ... 23.05.44 # still, working with the old hardware is fun :) 23.05.59 # <[Saint]> Oh, agreeable. If only all of them had decent internal amps and SQ> 23.06.35 # <[Saint]> All of them can do audio. Not all of them are any good at it. :) 23.06.51 # well, those kids these days don't care too much about quality. 23.07.01 # at least the marketing target group :) 23.07.27 Quit Strife1989 (Quit: Heading out.) 23.07.35 # lorenzo92: does the YP-R1 hardware do it as well or is that different to the R0? 23.07.36 # <[Saint]> everything is streamed now, no room for quality. 23.07.41 # <[Saint]> until maybe....opus. 23.08.01 # bluebrother: kinda similar, same cpu, same firmware format and same kernel 23.08.05 # i have it too 23.08.11 # ok. 23.08.21 # <[Saint]> But widespread adoption would still be far off even if it was adopted by manufacturers today. 23.08.28 # I've seen a R1 on ebay. Maybe I should try getting it 23.08.37 # assuming it doesn't get too pricey 23.08.59 # i would buy an R0 instead, but just because it has micro sd and NO touch :D 23.09.13 # <[Saint]> Yeah, R0 23.09.28 # <[Saint]> ask lorenzo92, I'm pretty sure he farms DAPs. 23.09.56 # for those I only get display protection thingies found on ebay 23.10.08 # haha well, I have 3 daps now ^^ 23.10.14 # but for hacking cramfs I don't need a device 23.10.22 # indeed haha 23.13.43 # X5 added! http://img14.imageshack.us/img14/6003/k7x7.jpg I also see a Samsung player needing Rockbox here :D 23.16.37 # <[Saint]> Is RoLo known broken? 23.17.00 # you collect classic mp3 players? :D 23.18.16 # ZincAlloy: not only classic mp3 players but basically all mp3 players :) On the pic that's only 7 out of 78 23.18.29 # oh my 23.18.43 # that's plenty 23.18.46 # bluebrother: oh! i actually found several copies of md5.c/.h in different parts of rb repo, i will do the same hihi 23.20.08 # Build Server message: 3New build round started. Revision 49bcf35, 217 builds, 18 clients. 23.20.53 # <[Saint]> what the hell? 23.21.04 # <[Saint]> Rockbox keeps stating the smae version number. 23.21.16 # <[Saint]> but the fs is fine, and the update *is* applying. 23.21.32 # <[Saint]> and RoLo doesn't seem to work. 23.21.37 # <[Saint]> Nooooooooooo! 23.22.02 # <[Saint]> My beautiful CF'd, micro-USB'ed, bluetooth'ed Color may be dying. 23.22.14 # * [Saint] weeps 23.22.57 # I have a h10 that is showing similar symptoms since years. 23.23.10 # it's mostly collecting dust though, so ... :) 23.23.53 # <[Saint]> I need to use this one today. 23.24.00 # <[Saint]> luckily it still has audio on it :) 23.24.10 Quit kevku (Ping timeout: 259 seconds) 23.24.11 # <[Saint]> and, the codecs appear fine, and /half/ of the UI works. 23.24.16 # use a different one :) 23.25.14 # <[Saint]> That would require being in a place I'm not. :) 23.27.40 # Build Server message: 3Build round completed after 452 seconds. 23.28.17 Quit [Saint] (Remote host closed the connection) 23.29.19 Join [Saint] [0] (~saint@rockbox/user/saint) 23.32.45 # bluebrother: got rid of openssl ;) 23.33.24 Join wipt_ [0] (~wipt@c-76-17-187-80.hsd1.mn.comcast.net) 23.33.59 # will rockbox ever support opus for recording? 23.35.25 # or does opus have too much complexity for most targets? 23.35.53 # wipt_: probably the letter 23.36.30 # wodz: mp3 is that much simplier? 23.37.02 Quit Rower (Read error: Connection reset by peer) 23.39.47 # wipt_: 1) it is simpler 2) it is much better optimized 23.43.29 # lorenzo92: nice :) 23.45.07 Quit pamaury (Ping timeout: 248 seconds) 23.49.53 # i think opus encoding is not too slow, but i'm not too interested in working on it in rockbox since i don't see that it matters when we have lossless options and pcs for encoding 23.50.03 # would probably take a lot of work to get the code well optimized 23.57.43 # Well, we're going to be doing a bunch of that work anyway. 23.57.57 # Because we need it to work on mobile for WebRTC.