--- Log for 26.10.105 Server: clarke.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 12 hours and 45 minutes ago 00.00.37 # man, i love overflow errors 00.04.32 Quit linuxstb (Read error: 110 (Connection timed out)) 00.05.17 Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 00.09.19 Quit ender` (Read error: 113 (No route to host)) 00.13.37 # * linuxstb has just found the ffmpeg 24-bit FLAC bug 00.13.43 # Overflow errors... 00.15.44 Join miner49er [0] (n=522e3819@labb.contactor.se) 00.15.56 Quit DrMoos (Read error: 104 (Connection reset by peer)) 00.17.12 # haha 00.17.23 # so it's a bug, not a feature? 00.18.16 # The problem is that ffmpeg itself is limited to 16-bit audio. Or at least, the flac decoder only outputs 16-bit samples at the end of the process. 00.18.34 # So nobody had tested 24-bit files. 00.19.25 # how well thought out 00.19.34 # Does your EMAC lpc_restore function deal with the "wide" case? 00.19.46 # I was about to look, but as you are here... 00.19.49 # i love this, the lowshelf filter goes on for about a second, then suddenly, starts bursting noise at certain intervals 00.19.54 # linuxstb: yes, i think so 00.20.08 # Can you remember how much of a speed improvement those functions gave? 00.20.14 # linuxstb: not at all 00.21.30 # but yeah, libflac has lpc_restore routines for both 16 bits, and everything above, it seems 00.21.36 # my routine handles both right now 00.21.47 # that's one of the things i might optimise 00.22.11 # Yes - it has routines optimised for 32-bit ints (where overflow is not a problem), and 64-bit routines otherwise (mainly for 24-bit audio I think). 00.22.18 # making a separate routine for 16 bit data, i think the 16 bit mac operation is faster 00.23.02 # There's an if statement in libFLAC that decides whether there is a risk of overflow or not. That was missing in ffmpeg, and ffmpeg always used the 32-bit version. 00.23.12 # Hence the overflow. 00.23.27 # But it was interesting to compare the ffmpeg and libFLAC code. 00.24.29 # anything notable? 00.26.02 # The actual libFLAC decoding code is perfectly normal - it's the layer upon layer of code above it that's the problem. 00.26.35 # In fact, I'm tempted to change the ffmpeg decoder so it looks more similar to libFLAC - to try and spot any other possible bugs. 00.27.12 # what i dislike about the libflac code is the structure 00.27.24 # Maybe we were just using libFLAC in the wrong way - i.e. we should be using the lower-level functions and strip out a lot of the higher-level stuff. 00.27.34 # sure, if that's possible 00.27.41 # i haven't had a look at the api at all 00.28.23 # But I think ffmpeg is the way to go. I'm now getting matching md5sums for both 16-bit and 24-bit files, so it's good enough for me. 00.28.39 # ffmpeg just needs a little more tidying up. 00.30.04 # any easily optimisable spots? 00.30.51 # I haven't really looked at that side of it yet. The lpc_restore function is the obvious choice - using your EMAC routine from libFLAC 00.31.17 # The bitreading functions might be able to be optimised as well, but I haven't looked at those at all. 00.31.40 # could you paste me a source url again, please? 00.31.48 # We've also got about 10KB left of IRAM. 00.31.55 # Yes, I'll make a fresh archive. 00.33.01 Nick Gibbed is now known as Rick (i=rick@pool-71-108-9-40.lsanca.dsl-w.verizon.net) 00.33.21 # god, i'm looking forward to when people will start asking for eq visualisation 00.33.22 # http://www.davechapman.f2s.com/rockbox/newflac.tgz 00.34.25 # hmm 00.34.32 # you can't use the libflac asm routines as is 00.34.58 # Why not? 00.35.44 # looks like arrays are set up slightly differently 00.35.57 # I was just about to look at it before I gave you the source. 00.36.18 # residuals are stored in the sample arrays, for one 00.37.34 # hmm 00.38.34 # it's got a loop where i need to use fractional emac mode here 00.38.46 # i wonder why i didn't have to do that in libflac 00.39.43 # Which loop is that? 00.40.07 # forget it 00.40.13 # i haven't optimised that for libflac either 00.40.35 # decode_subframe_lpc, lower part of the lower if 00.40.51 # The wsum part? 00.41.13 # yup 00.41.24 # is that for files with a bitdepth of more than 32, or what? 00.41.27 # That's the code I just had to add to fix 24-bit output. 00.41.31 # ouch 00.41.48 # It's the equivalent of lpc_restore_wide in libFLAC 00.41.55 # yeah, i figured 00.42.09 # well, optimising that might prove hard 00.42.12 # I haven't tested that on the iRiver yet. 00.42.27 # we might have to go the same route we did in libmusepack 00.43.02 # I don't think it will be executed for 16-bit FLAC files though. So it's not that important. 00.43.07 # nor do i 00.43.31 # Also, FLAC is very bad at compressing 24-bit files. wavpack is a much better choice. 00.43.46 # wavpack is a much better choice overall 00.43.49 # if you ask me, at least 00.44.34 # My 24-bit/44.1KHz FLAC examples are almost 1500kbit/s 00.44.54 # damn, that's bad 00.45.03 # how much for wavpack? 00.45.10 # I'll test now. 00.45.23 # wavpack can even compress 32 bit floats 00.45.26 # it's pretty l33t 00.45.48 # The file is 66% of the size - so I guess around 1000kbit/s 00.45.54 # wow 00.46.02 # Compressed in 3 seconds. 00.46.26 # On a 2.8GHz Xeon. 00.46.56 # but right now i'd give a pretty penny to understand what the flaming hell is wrong with this filtering routine 00.47.20 # coef calculation is very precise, but the filtering itself seems to have some internal overflow problem 00.47.27 # only problem is it's supposed to be impossible... 00.47.29 # Sorry, I made a mistake. Wavpack is about the same as FLAC - 1432kps 00.47.48 # The FLAC is 1496kbps 00.47.56 # ahh, ok 00.48.03 # about the same margins as for 16 bit audio, then 00.48.18 # wavpack tends to be slightly better 00.49.20 # Any idea if wavpack is easier to decode than FLAC, or is it just that David did a very good job. 00.50.30 # i have no idea, really 00.50.33 # i think a bit of both 00.52.05 # I'm hoping we can get FLAC to a similar level. 00.53.21 # would be nice, yeah 00.55.52 # Ouch. My 24-bit files have about a 70% boost ratio. Compared to less than 10% for 16-bit files. 00.56.24 # But they are playing perfectly. 00.56.41 # well, go figure 00.56.51 # it's suddenly 64 bit mul-o-rama in that code path 00.57.15 # rest assured we can slice that drastically 00.57.20 # but it'll always be slower, of course 00.57.34 # I hope so. It's now boosting near 100% and pausing. 00.57.48 # we can use the same trick we did in libmusepack 00.58.36 # * linuxstb goes and checks the cvs logs 01.00.24 # combining an emac mul and an ordinary mul to do a 64 bit mul 01.00.40 # amiconn also codec a much faster 64 bit shift 01.00.45 # coded 01.02.12 # Do you think we will get lots of complaints if I commit this new decoder before adding seeking support? 01.02.43 # It seems that seeking is actually quite hard in FLAC files - mainly because each compressed frame doesn't include the frame length. 01.03.43 # but flac files have seek tables, yeah? 01.04.12 # don't know about complaints, but i'd say just commit it 01.04.17 # Yes, but I think you still need to walk through the stream a little afterwards. 01.05.01 # Have you read the bug reports on the forum thread I started about this decoder? 01.05.25 # yup 01.05.38 # I think these are general problems, not specific to my new decoder. But I'm not sure. 01.05.55 # It seems some people are using old installations as well. 01.06.06 # i'm sure they are as well 01.06.19 # can't imagine how it can be otherwise 01.07.48 # OK, I'll probably commit it tomorrow. Just to give others a chance to complain if they read this in the logs. 01.10.31 Quit miner49er ("CGI:IRC") 01.11.26 # sounds good 01.15.19 # * preglow kicks the lowshelf filter 01.15.21 *** Saving seen data "./dancer.seen" 01.15.46 # Also, does anyone know why plugins/Makefile still links everything against the codec libraries? Is this just a leftover from the xxx2wav plugins and can be deleted? 01.17.48 # no idea 01.17.52 Quit SeeSchloss (Read error: 110 (Connection timed out)) 01.27.34 # Looks like podzilla now runs on the Nano - so IPL has arrived. 01.34.40 # now there's a good excuse to get one if i ever heard one 01.35.09 # I'm just about to test podzilla for the first time on my ipod. 01.37.00 # preglow: As for the 64 bit shift-by-n routine, the idea is taken from the gcc routine, of course optimised ;) 01.38.44 # It also profits from the fact that we only need 32 bits of the final result 01.42.17 # yup 01.42.47 # ok, i'm really starting to hate fixed point now 01.43.02 # Fixed point is great ;) 01.43.14 # mandelbrot.rock uses fixed point as well 01.43.39 Quit cYmen ("zZz") 01.43.51 # Format is 6.26, or 6.10 for low precision 01.44.02 # yes, it's nice enough, but i'm not used to these kind of errors! 01.46.25 # i'm really starting to grow sceptical about how fast a five band eq will be 01.48.13 # quite luckily the filtering loop should be a breeze to write in asm 01.59.38 # hi 02.00.08 # anyone here still awake who speaks english well ? 02.09.34 # I'm almost awake and English is my first language. 02.11.41 # cool ;) 02.12.01 # well I wrote a motivation letter 02.12.15 # to find an internship in japan 02.12.43 # but since english is not my mother tongue, it may not be very good 02.12.53 # would you mind looking at it ? 02.13.23 # I was about to go to bed. But if it can wait about 8 hours, I'll be happy to look at it in the morning. 02.13.41 # hmm 02.13.55 # Oh go on then. dave at dchapman.com :) 02.14.05 # I would like to send it right now for them to read it in the morning 02.14.23 # Yep - send it now and I'll have a look. 02.14.51 # hmm 02.14.56 # i put it on a ftp 02.15.01 # no problem. 02.15.10 # just tell me the big fault, it hasn't to be 100% correct 02.16.04 # It's already 9.15am in Tokyo... 02.16.23 # http://timidzone.free.fr/pub/motivation.txt 02.16.28 # yes I know :) 02.16.34 # I'm late :/ 02.16.37 Join tvelocity [0] (n=tony@ipa135.6.tellas.gr) 02.16.47 # (it's not very long) 02.17.42 # s/finishing in my/finishing my/ 02.17.56 # ok 02.18.06 # Probably best to write "I am" instead of "I'm" in a formal letter. 02.18.33 # ok I remve all the ' :p 02.18.56 # ingineer should be engineer 02.19.37 # ouch I'm not very awake too :) 02.19.45 # In fact, I'll just edit it slightly and upload a new version. 02.20.01 # ok 02.20.18 # thnk you very much (you save my life !) 02.22.26 # japanese people kill people with bad english? :P 02.22.48 # no wonder they've got plenty of suicides, then 02.23.01 # linuxstb: I just had a quick look at alac.c - your clz routine is indeed rather inefficient 02.23.24 # Dunno how much it is called though 02.23.40 # preglow: hmm I don't even know if they understand english well :p 02.23.59 # gcc has a rather clever clz routine 02.24.24 # TiMiD: most people don't 02.24.52 # so you'll have plenty of incentive to brush up on your spoken japanese 02.25.03 # TiMiD: http://www.davechapman.f2s.com/rockbox/motivation.txt 02.25.11 # Just minor changes - it was basically fine. 02.25.32 # thank you very very much :) 02.25.34 # I have one problem - "passionated" isn't a word. But I can't think of an alternative in that context. 02.26.03 Join ashridah [0] (i=ashridah@220-253-120-138.VIC.netspace.net.au) 02.26.24 # amiconn: What is the clz routine? 02.26.32 # hmm 02.26.58 # how would you say to have a passion ? 02.27.20 # That's the problem, I can't think of a way to say that. I guess English people don't have passions :) 02.27.24 # count_leading_zeros() 02.27.31 # hehe :) 02.28.11 # I don't see another way to say it either :/ 02.28.17 # amiconn: Yes. But it's not my function. The author even admits how awful it is. 02.28.24 # (in french you would say it like that) 02.28.38 # I could find 'passionate' in my English-German dictionary 02.28.47 # doesn't fit 02.29.07 # Yes - just say "I am passionate about ..." 02.29.36 # linuxstb: Okay, so it's by the alac author, and yes, I read the comment 02.29.38 # impassioned works ? 02.29.47 # (I found it in the dictionnary) 02.30.07 # TiMiD: "I am passionate about" fits your sentence perfectly. 02.30.13 # ok :p 02.30.57 # linuxstb: I hope you used the 'correct' iram attributes for your new flac codec? ;) 02.31.28 # Do they work in the codecs? 02.31.28 # http://aggregate.org/MAGIC/#Leading Zero Count 02.31.41 # linuxstb: yes 02.32.22 # when I think they will more probably use an automatic translator to understand this beautifull :( 02.32.25 # There's no real difference yet, except ICONST_ATTR allows putting const data into iram without dropping the 'const' 02.32.31 # +letter 02.32.45 # haha 02.33.05 # Using the correct attributes will help to see whether it's worth adding proper .ibss handling for codecs 02.33.23 # hey let him go to bed now :) 02.33.31 # I think it will be - flac.codec for example reduces down to about 8300 bytes without the buffers. 02.33.52 # Nice :) 02.34.02 # oh? 02.34.02 # It's scary. 02.34.21 # so there's room for all of the codec in iram? 02.34.29 # preglow: Yes, that's what I said the other day. 02.34.51 # how much is your codec in size ? 02.34.53 # there's still a lot of unused iram around for all codecs 02.35.00 # Theres about 38KB of buffer and 8K of code.http://timidzone.free.fr/pub/motivation.txt 02.35.07 # oops. 02.35.11 # hehe :) 02.35.17 # lol 02.35.22 # Pesky clipboard. Never forgets. 02.35.28 # nono :) 02.35.35 # it's a virus in my .txt 02.35.46 # exploits a buffer averflow in notepad :p 02.36.25 # Back to the IRAM - I should be using IDATA_ATTR for the data, and ICONST_ATTR for any lookup tables? 02.37.27 # IDATA_ATTR for initialised data, ICONST_ATTR for constant data and (most important) IBSS_ATTR for uninitialised data, e.g. buffers 02.37.56 # I think IDATA_ATTR will actually be used least in codecs, if at all 02.38.23 # Yes - there is no use of it in my new FLAC decoder now. 02.41.08 # Even the core uses very little idata - 8 bytes (!) (h120) 02.41.22 # Plus 16 bytes iconst 02.41.27 Quit tvelocity ("Leaving") 02.43.42 Join webguest82 [0] (n=3a4d501d@labb.contactor.se) 02.43.46 # hi~ 02.47.32 Quit gromit` (Remote closed the connection) 02.47.44 # hmm 02.47.46 # hi webguest82 02.47.55 # there already is a db lookup table some place in rockbox? 02.50.26 # 28 mails to send 02.50.41 # the night will be short 02.52.32 # bye~ 02.53.04 # bye ? 02.53.14 # you are short 02.53.22 # :) 02.53.34 # i live in korea 02.53.39 # * preglow slaps the lowshelf filter 02.53.40 # I know :p 02.53.45 # i'm off to bed, night all 02.53.47 # I read the logs 02.53.51 # gnight 02.54.24 # It goes to the school. 02.54.43 # good night 02.55.00 Quit webguest82 ("CGI:IRC (EOF)") 03.01.06 # Msjpcrc@microsoft.com 03.01.30 # -________- 03.02.46 # Goodnight all. Good luck TiMiD. 03.05.16 Join gromit` [0] (n=gromit`@ras75-5-82-234-244-69.fbx.proxad.net) 03.06.47 # thank you :) 03.10.38 Quit lostlogic (Read error: 110 (Connection timed out)) 03.15.23 *** Saving seen data "./dancer.seen" 03.33.43 Join Midgey34 [0] (n=43ac4434@labb.contactor.se) 03.41.55 Join lostlogic [0] (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net) 03.44.52 Quit gromit` (Remote closed the connection) 03.59.58 Quit Midgey34 ("CGI:IRC") 04.04.14 Join alxcm [0] (n=alx@hc6527651.dhcp.vt.edu) 04.04.18 # sup ppl? 04.04.47 Join Midgey34 [0] (n=chatzill@c-67-172-68-52.hsd1.mi.comcast.net) 04.06.09 Join _Vladoman [0] (n=Vladoman@p54A7C746.dip.t-dialin.net) 04.08.48 # odd 04.08.52 # "Codec Failure" 04.09.03 # when trying to play anything using today's daily build on my ihp120 04.17.18 Quit QT (Read error: 110 (Connection timed out)) 04.21.36 Quit novimon (Read error: 110 (Connection timed out)) 04.23.59 Join gursikh [0] (n=gursikh@adsl-68-92-219-124.dsl.hstntx.swbell.net) 04.24.20 Quit Vlad0man (Read error: 110 (Connection timed out)) 04.25.06 # Hello 04.39.48 Part gursikh 04.56.01 Join myndzi [0] (i=myndzi@myndzi.seckzi.com) 04.56.08 Part myndzi 05.15.26 *** Saving seen data "./dancer.seen" 05.22.05 Nick Midgey34 is now known as MijZZZ (n=chatzill@c-67-172-68-52.hsd1.mi.comcast.net) 05.27.09 Join webguest56 [0] (n=43467ddc@labb.contactor.se) 05.27.23 # hello 05.28.45 Quit webguest56 (Client Quit) 05.45.08 Nick ashridah is now known as Lost-ash (i=ashridah@220-253-120-138.VIC.netspace.net.au) 06.02.21 Join MijZZZ_ [0] (n=chatzill@c-67-172-68-52.hsd1.mi.comcast.net) 06.07.43 Join MacDancer [0] (n=MacDance@adsl-69-106-226-149.dsl.pltn13.pacbell.net) 06.18.20 Quit MijZZZ (Read error: 110 (Connection timed out)) 06.24.04 Nick Lost-ash is now known as ashridah (i=ashridah@220-253-120-138.VIC.netspace.net.au) 07.01.46 Join amiconn_ [0] (n=jens@p54BD470E.dip.t-dialin.net) 07.15.27 *** Saving seen data "./dancer.seen" 07.17.07 Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 07.17.57 Join SeeSchloss [0] (n=SeeSchlo@this.is.not.a.hostname.ssz.fr) 07.20.07 Quit amiconn (Read error: 110 (Connection timed out)) 07.20.08 Nick amiconn_ is now known as amiconn (n=jens@p54BD470E.dip.t-dialin.net) 07.53.45 Quit ghode|afk (Read error: 110 (Connection timed out)) 08.02.46 Quit MacDancer ("Leaving") 08.05.21 Join ender` [0] (i=ychat@84.52.165.220) 08.11.45 Join B4gder [0] (n=daniel@static-213-115-255-230.sme.bredbandsbolaget.se) 08.11.47 Quit matsl (Remote closed the connection) 08.20.48 Join Lost-ash [0] (i=ashridah@220-253-123-54.VIC.netspace.net.au) 08.21.10 Quit ashridah (Nick collision from services.) 08.23.25 Nick Lost-ash is now known as ashridah (i=ashridah@220-253-123-54.VIC.netspace.net.au) 09.03.40 Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) 09.06.59 Part amiconn 09.12.06 Join solexx [0] (n=jrschulz@d001161.adsl.hansenet.de) 09.12.53 Join amiconn [0] (n=jens@p54BD470E.dip.t-dialin.net) 09.15.29 *** Saving seen data "./dancer.seen" 09.27.11 Quit solexx_ (Read error: 110 (Connection timed out)) 09.27.37 Quit Lynx_awy (Read error: 104 (Connection reset by peer)) 09.36.34 Join Lynx_ [0] (n=lynx@tina-10-4.genetik.uni-koeln.de) 09.41.28 # amiconn (or anyone who's interested): I've updated the unicode patch with the changes you asked for 09.41.41 # could you have another look when you have time? 09.42.19 # I also managed to shave a couple hundred bytes off the binary size :) 10.06.42 Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) 11.05.07 Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 11.15.30 *** Saving seen data "./dancer.seen" 11.26.10 # phaedrus961: yes, tonight 11.26.53 Quit cYmen (Read error: 104 (Connection reset by peer)) 11.29.48 Quit markun (Read error: 104 (Connection reset by peer)) 11.30.33 Join muesli- [0] (i=muesli_t@hmln-d9b8efa3.pool.mediaWays.net) 11.30.42 Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 11.30.59 Join markun [0] (n=karl@bastards.student.ipv6.utwente.nl) 11.33.12 Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) 11.35.53 Join cYmen_ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 11.41.07 Join cYmen__ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 11.48.42 Quit cYmen (Connection timed out) 11.49.10 # Morning all. 11.50.33 # Good mornig 11.50.46 # preglow and I are both in favour of comitting the new flac decoder immediately (even though there is no seeking yet). Does anyone object? 11.50.51 # g'day m8s 11.51.20 # First step to arabic rockbox: http://130.89.160.166/rockbox/arabjoin.png 11.52.48 # the first line shows the current rendering. The second line is produced with a script that makes it joining. 11.53.43 Quit cYmen_ (Connection timed out) 11.55.13 Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 12.00.45 # I've just realised why plugins/Makefile still links against the codec libs - the wav2wv plugin. 12.03.53 Quit linuxstb (Read error: 113 (No route to host)) 12.17.55 Quit linuxstb_ (Read error: 104 (Connection reset by peer)) 12.21.40 Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 12.24.22 Quit MijZZZ_ ("Chatzilla 0.9.68.5.1 [Firefox 1.0.7/20051010]") 12.26.12 Nick ashridah is now known as Lost-tv (i=ashridah@220-253-123-54.VIC.netspace.net.au) 12.27.58 Quit muesli- (Read error: 113 (No route to host)) 12.31.01 Nick linuxstb_ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net) 12.52.03 # Strange. I was playing music, then plugged in USB (with the music playing), and now I can hear a very faint radio signal in my headphones. 12.52.17 # I haven't listened to the radio for days. 12.53.08 # Hmm, that must be some other interference :) 12.53.40 # Maybe. I just left USB mode (back to file browser), and it's silent again. 13.06.03 Quit ryan_j (Read error: 110 (Connection timed out)) 13.15.34 *** Saving seen data "./dancer.seen" 13.20.02 Join ryan_j [0] (n=ryanj@c-24-10-241-46.hsd1.ut.comcast.net) 13.21.22 Join ripnetuk [0] (n=george@82-70-100-230.dsl.in-addr.zen.co.uk) 13.27.53 Join _DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) 13.33.14 Nick Lost-tv is now known as ashridah (i=ashridah@220-253-123-54.VIC.netspace.net.au) 13.35.38 Quit ripnetuk ("Ninja IRC v1.5.8.1(#1) exiting after 14m16s of use") 13.40.31 Join Vlad0man [0] (n=Vladoman@p54A7C746.dip.t-dialin.net) 13.43.23 Quit DangerousDan (Read error: 110 (Connection timed out)) 13.58.15 Quit _Vladoman (Read error: 110 (Connection timed out)) 14.01.12 Join muesli- [0] (i=muesli_t@hmln-d9b8ef52.pool.mediaWays.net) 14.05.29 # re 14.11.43 # hi muesli- 14.11.57 # hi 14.37.17 # nice commit linuxstb! 14.37.33 # * preglow applaudes 14.37.40 # * linuxstb bows 14.37.59 # Now the fun commit - removing libFLAC :) 14.38.10 # hmm 14.38.21 # can't that wait for a bit? 14.38.23 # Sure. 14.38.31 # we might for some reason need to put it back in again 14.38.50 # might as well wait until the new flac decoder is fully operations 14.38.54 # operational <- 14.39.05 # OK. I removed it from FILES, and it's not compiled any more. So there's no harm in leaving it there. 14.39.45 # preglow, amiconn: Please feel free to work some EMAC magic on it. 14.41.39 # will see what i can do 14.42.01 # think i'll just modify the unrolled libflac one and drop it in somehow 14.46.53 Join novimon [0] (n=novimon@a84-230-230-239.elisa-laajakaista.fi) 14.48.46 # btw, does the wavpack decoder play 24 bit files with a big speed penalty as well? 14.48.51 # if i remember correctly, it shouldn't 14.49.56 # I remember seeing lots of 16-bit/44.1KHz assumptions in the code, but I haven't checked recently. 14.50.17 # Maybe that was just the old wv2wav plugin though. 14.51.00 # i think so 14.51.09 # wavpack already uses a 64 bit mul, even for 16 bit data 14.51.14 # so i think it should be able to cope very nicely 14.51.16 # w00t, new flac encoder! 14.51.19 # must check out 14.51.20 # decoer! 14.51.24 # decoder, even 14.51.25 # decoder! :D 14.51.31 # the old one was bugged 14.51.48 # linuxstb: you think it'll be hard to add seeking? 14.51.49 # How do you mean bugged? The only problem I knew about was that it was slow. 14.52.00 # preglow: Not really. Just needs a couple of hours of concentration. 14.52.16 # I should be able to do it in the next few days. 14.52.21 # yeah the seeking was very very slow and the decoder used to skip 14.52.29 # not so often thou but from time to time 14.52.52 # Sadly, seeking is quite hard in raw FLAC files. OggFLAC would be better in this regard. 14.53.39 # The size (in bytes) of a compressed frame isn't stored in the frame header. So you need to partially decode the frame in order to find its length. 14.54.48 # I'm not sure how accurate the seek table normally is, but I'm guessing the implementation will be to seek to the closest frame using the seek table, and then walk the stream until we get to the correct frame. 14.55.58 # a non-accurate seek table 14.56.00 # what a concept 14.56.18 # I mean the resolution of the seek table. 14.58.15 # ahh, like that 14.58.45 # Just checked - the default behaviour of the reference encoder is to insert seek points every 10 seconds. 14.58.51 Join webguest82 [0] (n=3a4d501d@labb.contactor.se) 14.59.10 # hi~ 14.59.35 # linuxstb: that's not bad 15.00.02 # No. I'll probably do a first implementation that just seeks to the nearest seek point. 15.00.32 # It will be better than nothing. 15.00.50 # indeed 15.00.55 # Why no interpolate between seekpoints, like with mp3 vbr? 15.01.00 # *not 15.01.22 # that'll come 15.01.51 # it'll become important when we are to support cue files 15.02.16 # That's one approach - but you then have to sync to the start of the frame. Which is not easy as the sync code is not guaranteed to not appear inside frames. 15.02.30 # Imho we shouldn't support .cue files at all 15.02.41 # why not? 15.02.51 # .cue support would be awesome 15.03.01 # If a FLAC file has an embedded cue file, then the cue points should have corresponding entries in the seek table. 15.03.22 # .cue files are a broken concept, imho 15.03.35 # They are for when the player doesn't support gapless. 15.03.39 # nevertheless there are a lot of files using them out there 15.04.07 # They have other uses - think of them as "chapter points" in a long recording. Other formats (such as m4a) include chapter points. 15.04.24 # It is nice in some situations to not have to split your long file into individual tracks. 15.05.04 # But I agree that they are often used as a workaround for players not supporting gapless. 15.05.23 # sure, me too 15.05.31 # but there are still nevertheless quite a lot of them around 15.05.39 # and i'd like to have them supported 15.05.44 # wavpack files also support embedded cue files 15.05.48 # flac too, i believe 15.06.18 # Yep. People use them to backup CDs to a single file. 15.11.07 # Really? I can't believe that, especially with lossless 15.12.03 # I don't really understand, but I think a cuefile is needed for a 100% accurate backup. Storing things like CD-TEXT, hidden tracks etc 15.12.06 # what's so hard to believe about it? i'd do it myself if i ever backed up my cds losslessly, heh 15.15.37 *** Saving seen data "./dancer.seen" 15.15.49 Join webguest38 [0] (n=daea8787@labb.contactor.se) 15.15.59 # There are 2 points I don't understand: (1) Why should I backup a CD I have myself as lossless? (2) If I had a reason, why would I convert it to a single file and cuesheet? 15.16.31 # 1) The same reason you back up anything of value 15.16.34 # I'd rather use individual files per track. They are more convenient to handle, especially with lossless 15.16.45 # Lossless files are huge 15.16.48 # hi webguest38 15.17.06 Quit webguest38 (Client Quit) 15.18.11 # 2) Because you want to preserve the CD perfectly. But on this point I agree with you - backing up to individual tracks is good enough for me. 15.19.27 Quit Zagor (Read error: 110 (Connection timed out)) 15.20.32 # linuxstb: I consider the CDs as my backup. I only rarely play directly from CD once I ripped them (to lossy format, single tracks) 15.22.14 Join Zagor [0] (n=bjst@pdpc/supporter/sustaining/Zagor) 15.22.43 # I'm not saying that _you_ must back up your CDs. Just that lots of other people do. I'm guessing those people actually play their CDs in a CD player. 15.22.59 # heh. i rarely play cds directly. 15.23.06 # (for obvious reasons) 15.23.28 # i play cds all the time when i've got my cd player rigged up 15.23.30 # which i haven't now 15.23.31 # There is always the risk of theft as well. 15.23.45 # but i understand why people back up cds perfectly 15.23.50 # i just don't do it myself 15.24.13 # linuxstb: that one's bitten me. lost a lot of cds i didn't have in mp3 format at the time (ogg wasn't even v1.0 back then, flac was unknown to me) 15.25.36 Quit ashridah ("Leaving") 15.28.50 Quit novimon ("Changing server") 15.35.34 Quit webguest82 ("CGI:IRC (EOF)") 16.09.41 Quit SeeSchloss (Read error: 110 (Connection timed out)) 16.29.53 Quit B4gder ("time to say moo") 16.50.05 Join _FireFly_ [0] (n=icechat5@p54A45544.dip.t-dialin.net) 16.59.38 Join actionshrimp [0] (i=dave@dhcp-163-1-214-173.seh.ox.ac.uk) 17.15.40 *** Saving seen data "./dancer.seen" 17.26.42 Quit muesli- (Read error: 113 (No route to host)) 17.32.12 Join SeeSchloss [0] (n=SeeSchlo@this.is.not.a.hostname.ssz.fr) 17.48.22 Join XavierGr [0] (n=XavierGr@ppp12-adsl-111.ath.forthnet.gr) 18.00.49 Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) 18.10.54 Join ghode|afk [0] (n=garudin@host-212-158-193-204.bulldogdsl.com) 18.24.57 Join tvelocity [0] (n=tony@ipa135.6.tellas.gr) 18.26.12 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 18.45.13 Quit Mxm`Pas`Bien (Read error: 104 (Connection reset by peer)) 18.45.20 Join Maxime [0] (n=flemmard@sav67-1-82-227-75-27.fbx.proxad.net) 19.06.04 Quit Maxime () 19.15.18 Quit SeeSchloss (Read error: 110 (Connection timed out)) 19.15.40 Join SeeSchloss [0] (n=SeeSchlo@this.is.not.a.hostname.ssz.fr) 19.15.41 *** Saving seen data "./dancer.seen" 19.20.14 Nick paugh is now known as AliasCoffee (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) 19.43.10 Nick Lynx_ is now known as Lynx_awy (n=lynx@tina-10-4.genetik.uni-koeln.de) 19.52.29 Quit Lynx_awy (Read error: 104 (Connection reset by peer)) 19.52.49 Quit linuxstb (Read error: 104 (Connection reset by peer)) 19.53.10 Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 19.55.21 Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 20.04.23 Quit linuxstb (Read error: 113 (No route to host)) 20.05.57 Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU) 20.19.32 Quit dpassen1 () 20.38.07 Quit _FireFly_ ("Famous last words") 20.48.38 Join Febs [0] (n=40be24f0@labb.contactor.se) 21.15.42 *** Saving seen data "./dancer.seen" 22.20.30 # Hey guys! very quite day today :-) 22.21.25 # markun/phaedrus961/amiconn: what's new about unicode ? 22.23.19 # or preglow: what's new about your EQ? :D 22.28.19 # why was the flac codec replaced? 22.28.44 # because the new one is much faster. 22.29.09 # decoding happens almost without cpu boosting. 22.29.20 # ah... nice :) 22.36.45 # hi Moos 22.37.07 # today 55 mails ^^ 22.37.27 # ouch 22.37.32 # hi btw 22.40.17 Quit dwihno (Read error: 110 (Connection timed out)) 22.44.09 Join Bagder [0] (n=daniel@1-1-5-26a.hud.sth.bostream.se) 22.49.26 # 55 mails? where? 22.50.56 # japan companies 22.51.15 # Moos: not much new, something wrong i need to figure out 22.51.39 # once that is done, i just need to integrate it into rockbox and make some gui for it 22.51.40 # ok, have a good "luck" :) 22.51.42 # TiMiD: Why are you going to work over Japan? 22.51.54 # preglow: oh, that sound good 22.52.25 # Moos: might still take some time, don't hold your breath 22.52.25 Join dwihno [0] (n=dw@81.8.224.89) 22.52.29 # XavierGr: I'm indeed trying to 22.52.35 # preglow: Where do you think that the user will get the EQ gui? Inside Playback settings maybe? 22.52.54 # preglow: but good to hear you are working on it :) 22.53.08 # XavierGr: well, i guess so 22.53.10 # TiMiD: So you are going to move over to Japan? Why go this far? 22.53.26 # XavierGr: personally i'd like a full graphical eq like screen, but i can't be bothered to do that 22.53.32 # You are in France, aren't you? You can choose another EU country as well 22.53.45 # XavierGr: because I'm a manga maniac ^^ 22.53.47 # or the FRANCE as well :) 22.53.50 # there is quite a difference between an eu country and japan, you know 22.53.50 # hhe 22.54.12 # well 22.54.17 # I don't know why 22.54.28 # preglow: That would be great, though once the EQ code is done the gui is just detail and can be done by abyone. 22.54.29 # I'm attracted by this culture and language 22.54.46 # (nothing to do with mangas though) 22.54.46 # XavierGr: yes 22.54.52 # it's just that 22.54.57 # i'd love to learn japanese 22.55.07 # So that is why you took Japanese as a lesson in your college, right? And what about your studies, did you finished? 22.55.10 # i tried once, but i stopped after a while 22.55.59 # depand in the motivation, if you want to work in Jap you could learn more easily 22.56.01 # I am learning Japanese through Anime series and movies! :) 22.56.09 # I will be done in january 22.56.13 # had no use for it apart from playing snes rpgs in their original language anyway, heh 22.56.13 # Konni chioua! 22.56.18 # XavierGr: ahahah 22.56.29 # you have some work to do on your spelling, young man! 22.56.42 # XavierGr: learn the kanas first, that will help you :) 22.56.46 # :p 22.56.47 # TiMiD: i did 22.56.55 # KO N NI CHI WA 22.56.55 # TiMiD: forgotten most of them now, though 22.57.08 # or HA 22.57.22 # there's only one japanese word you need to know: BAKA 22.57.23 # if you don't prictice them it's hard :) 22.57.29 # lol 22.57.32 # I prefer AHOU 22.57.38 # anta baka? 22.57.41 # :D 22.58.03 # this is my favorite word! Especially wih the "anta" in front of it 22.59.10 # anata 22.59.11 # :) 22.59.19 # anata no baka 22.59.24 # So in what sort of job are you sending you CV for? 22.59.34 # for computer engineer 22.59.37 # baka yo 22.59.55 # Haiyaku, torihada-chen! 23.00.01 # attashi baka! 23.00.05 # :x 23.00.12 # watashi :) 23.00.21 # grrr 23.00.21 # hayaku 23.00.28 # I alwasys forget that 23.00.36 # but I should have said boku 23.01.08 # yep 23.01.21 # you'r not a woomen (who knows ^^) 23.01.29 # watashi sounds more cute! :) 23.01.50 # boku ~ baka you know.... 23.02.30 # linuxstb_: my, what i nice little codec libffmpegFLAC is 23.03.02 # Yes, I know :) 23.03.05 # if you say bak 23.03.14 # then tou can call yourself 'ore' 23.03.25 # since you don't use polite language ... 23.03.26 # speaking of it which is the most optimized codec so far? 23.03.28 # linuxstb_: but where does it store all the residuals and lpc and so on? does it use the pcm buffer for it or something? 23.03.41 # I've just tested wavpack with 24-bit files, and they play fine, about 25% boost. 23.04.16 # TiMiD: so any luck to get a job until now? 23.04.18 # Yes, I think they are stored in the "decoded" arrays - these are the only buffers it uses. 23.04.26 # linuxstb_: 36 KB ibss, ~670 bytes iconst, no idata 23.04.38 # I hope the other codecs are similar... 23.04.45 # linuxstb_: excellent, just excellent 23.04.49 # I removed the final "convert to 16-bit and copy to different buffers" stage from the codec, so it now does it everything in-place. 23.04.53 # linuxstb_: the libFLAC people have got a thing or two to learn here 23.05.02 # XavierGr: time will tell but I'm not vry confident ... 23.05.12 # I'll try USA if japan fails 23.05.28 # at least I would have done the maximum I could do so no regret 23.05.38 # XavierGr: the most optimised codec is probably libmad 23.05.50 # TiMiD: Truth is that there must be a lot of competition there for this kind of job. 23.05.55 # XavierGr: as in that's what's seen most optimisation work 23.06.10 # Silence all day, and then everyone talks at once.... 23.06.49 # preglow: libmad is vorbis? or... 23.06.55 # XavierGr: mp1/2/3 23.07.01 # If we would add separate bss and ibss handling, flac.codec would be a mere 9 KB... 23.07.20 # ah yes the MAD 23.08.45 # amiconn: and while i remember it, have you tested mp1 performance? 23.09.24 # I have just one mp1... but I could probably produce some test files with different bitrates 23.09.40 # nothing imporant, i'm just wondering how good/bad it is 23.09.45 # i haven't got even one mp1 file 23.09.59 # I can create them, with Pegase on Amiga 23.10.11 # ahh 23.10.16 # It's a rather good layer 2 encoder, but also does layer 1 23.10.59 # It's *really* fast compared to lame on Amiga, although not realtime 23.11.09 Quit _DangerousDan (Read error: 104 (Connection reset by peer)) 23.11.17 # So far I've managed to avoid malloc entirely in the new flac codec (libffmpeg had some which I removed). But the seek table will vary in size from about 200 bytes (for a typical 4 minute song with standard 10 second seek points) up to maybe 40KB-50KB for a very large (i.e. 2GB) file. 23.11.44 # On my A4000/060/50, lame is ~10% realtime with cbr and ~3% realtime with vbr. Pegase is ~50% realtime... 23.12.46 # Too bad it uses floating point... 23.15.38 # i wonder when christian gmeiner will return 23.15.43 *** Saving seen data "./dancer.seen" 23.15.59 Join muesli- [0] (i=muesli_t@hmln-d9b8efae.pool.mediaWays.net) 23.16.00 # I mailed him again a couple of days ago 23.16.19 # no reply so far 23.16.50 # you bought a bdm for him, no? 23.16.55 # yes 23.17.11 # I asked him to mail it back to us if he doesn't plan on using it for Rockbox 23.17.27 # re 23.17.28 # Perhaps I should do some layer 1 and layer 2 test files and put them on my webspace. It sits mostly unused... 23.17.46 # amiconn: would of course be nice, i have few such files myself 23.17.57 # Bagder: yes, giving it to some other interested party would be nice 23.18.05 # exactly 23.18.06 # preglow: What do you think would be useful bitrates to test with? Should I use our famous digital flow thingy? 23.18.49 # amiconn: you can do whatever you want in that regard, as for bitrates, the extremes would be nice, plus something in between 23.19.14 # i think 44.1 khz will do for sample rate, i don't see any point in testing the resampler any further 23.19.24 # i know it sucks anyway ;) 23.22.33 # I have 200MB webspace of which I'm currently using ~2MB only... 23.23.01 # may I ask what the current status of my patch is ? 23.23.02 Quit ender` (Read error: 104 (Connection reset by peer)) 23.23.06 # i've got five gigs of which i use around 10... 23.23.15 # megs, that is 23.23.26 # I'm a little bored to update it each time someone updates a file I modify 23.23.50 # TiMiD: afaik, none of the core devs have time to look at it 23.23.57 # i've got no idea about that area of rockbox, so can't help 23.24.48 # i think i'll see about adapting my libflac lpc patch 23.25.50 # amiconn: Do you have time to try out the unicode patch? There are some problems with the text viewer, but phaedrus961 said he will take a look at it. 23.25.53 # preglow do you have any realtion to the FM radio cado for iriver? I've got the preset file patch pending... :p 23.26.01 # lol 23.26.07 # XavierGr: no relation, no 23.26.10 # RPFLMAO 23.26.11 # all patches coming at the same time ^^ 23.26.16 # come to me for codecs and dsp, heh 23.26.54 # TiMiD: the time when Linus, Bagder... apear don't have lot of time :-( 23.26.57 # I only got LinusN and amiconn opinions about remote 23.27.10 # we all want it sure :) 23.27.10 # other one have looked at it ? 23.27.15 # don't be shy :) 23.27.25 # TiMiD: well, what more do you want? 23.27.44 # commit :D 23.27.54 # TiMiD: if you've got linus' and amiconn's opinions, you've got some very influential opinions and should probably do what they say ;) 23.28.01 # how was the feedback of Linus and amiconn, bar or good? 23.28.07 # I've done it :p 23.28.12 # ^bad 23.29.11 # preglow: I'll do a 'typical' and a maximum bitrate version for layer 1 and 2 each 23.29.13 # good :) 23.29.19 # I think 23.29.38 # layer 1: 256/448 kbps layer 2: 192/384 kbps 23.29.40 # LinusN was quite positive I think 23.29.54 # yeah he liked it :) 23.30.23 # but those last weeks he don't have time for Rockbox 23.30.56 # I cant wait for commitment, imagine full remtote support and full recording support that Slasheri is working on. 23.31.09 # Bagder: any opinion? 23.31.29 # it would be good then that some people test it on real targets (I only hve tested on sim and iriver) 23.31.52 # nad then if it doesn't beaks anything why not a commit 23.33.07 # TiMiD: why don't continu to work on it, currently just file tree; right? 23.33.31 # well I feel him 23.33.43 # because it would be such a huge work to maintain it 23.33.45 # you already know it will be one day or other for sure 23.33.54 # if this is not going to be commited there is no point to continue 23.34.00 # it will 23.34.13 # but it's still not in it 23.34.14 # but when, that is the question :) 23.34.16 # TiMiD: Does it break a lot when you use cvs update? 23.34.27 # break ? 23.34.36 # conflict 23.34.42 Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) 23.34.45 # Or do you not use cvs update? 23.34.55 # I use CVS update 23.35.06 # but I can't do it on my current source tree 23.35.16 # Why not? 23.35.22 # since some files are deeply modified 23.35.46 # I think as soon as either remote lcd or unicode gets committed, the other patch will suffer from a number of conflicts 23.36.00 # :/ 23.36.15 # Yes, probably. 23.36.42 # although I applied both TiMiD's patch and the unicode patch.. 23.36.57 # I don't mind if it's one other big update 23.37.03 # Can't remember many conflicts 23.37.18 # ooh 23.37.21 # i love big changes 23.37.27 # since I understand the code I can modify it 23.37.53 # but what I don'tlike is contant little changes to files day by day :D 23.38.06 # (welle it happens twice a week) 23.39.21 # TiMiD: I know exactly what you mean. I had to that for the remote patch (before Firefly). Though I knew that this kind of buggy work would never be commited i tried to update every day. Then I lost interest (I didn't had the time too) and the patch became obsolete. 23.39.53 # TiMiD: is it understandable, who love it :-( 23.40.00 # yep 23.40.10 # it's not an interresting work 23.40.21 # work of a machine :) 23.40.31 # :-( 23.40.47 # you don't have luck both you and Xavier 23.40.49 # that's why I didn't made a huge patch like firefly or xavier's wone 23.40.51 # TiMiD: I tried your patch again. No conflicts with the unicode patch, so that's good. 23.40.58 # ok 23.41.02 # great ^^ 23.41.11 # when Linus have time he applied patch, work... but those weeks busy 23.41.13 # I suppose you work in lower areas :p 23.42.21 # shit 23.42.40 # I was goingto write to an indian company ;) 23.43.04 # I think I'm done with mails for this evening 23.43.26 # (reposes toi ;-) ) 23.43.50 # at least you should use copy and paste TiMiD! 23.44.40 # lol 23.45.01 # do you think I type each mail with love and tenderness ? 23.45.42 # I have a template ready in my mailbox and I only have a few things to change 23.45.47 # Saiyu sen jiko yo <- is this phrase translates to very important or high priority? 23.46.48 # I don't know 23.46.54 # are you sure for the saiyu ? 23.47.22 # it is a very hilarious phrase that I hear on an anime series... 23.48.22 # well I typed it from a subtitle and yes it has the hearing of it, though I dont know if it is right 23.48.59 # is typing Jpanase in latin characters normal? 23.49.55 # if it was saiku I could say it would mean something like "very important work" or smth like that (I'm far far away from a good japanese speaker) 23.50.28 # then what are you going to do in Japan?? Just kidding... 23.50.45 # I wonder 23.52.44 # XavierGr: pretty normal, it's called romaji 23.52.56 # XavierGr: but mostly done by learners 23.53.10 # I find it difficult to read ;( 23.53.13 # That reminds me of Greeklish 23.53.14 # like pinjing in chinese 23.53.24 # I'm most used to hiraganas and some kanjis 23.53.27 # though it's usage is only in chatrooms 23.53.42 # XavierGr: why ? 23.53.53 # you can type japanes in chatrooms 23.54.02 # why use it only in chatrooms or forums? 23.54.10 # こんばんは 23.54.11 # or why use it at all? 23.54.15 # ? 23.54.25 # garbage 23.54.40 # it's UTF-8 23.54.49 # you must be in iso 23.55.21 # yes, what if I type this: ; 23.55.22 # looking at this asm again made me want a stiff drink 23.56.55 # lol 23.56.59 # Hmpfz :/ My provider doesn't allow dir listings on the server when there is no idex file 23.57.07 # *index 23.57.39 Quit Febs ("CGI:IRC (EOF)") 23.57.42 # TiMiD: The main usage of Greeklish (greek language written with latin characters) can be encountered only in chatrooms or informal Forum. 23.57.59 # btw we have denglish ;) 23.58.16 # and we have svengelska 23.58.23 # hehe 23.58.30 # and I love my french :) 23.58.32 # Friends in Colombia you Espanglish 23.58.49 # (no franglish doens't exists yet :p ) 23.58.52 # The main reason to use this is write a little bit faster because with only latin characters you represnt the word as it is read instead of writing it.