00:00:09 | Moos | if you prefer the H3xx series do it :) |
00:00:21 | Moos | Rockbox coming soon on it |
00:00:24 | XavierGr | Only if Rockbox is ready for it;) |
00:00:37 | ]RowaN[ | im i right in thinking... h3xx vs h1xx = color screen vs optical out |
00:00:40 | Moos | buy one before Rb for the price ;) |
00:00:46 | XavierGr | But if Rockbox is ready for the H300 it would beat h100 for sure. |
00:00:49 | Moos | you know Rb will be ported |
00:00:57 | Moos | not sure ;) |
00:01:03 | ]RowaN[ | or is there more to it? |
00:01:06 | Moos | depend of your choice |
00:01:16 | muesli- | Moos pray 4 it every day |
00:01:16 | muesli- | ;) |
00:01:19 | Moos | personnally I prefer a lot the H140 |
00:01:29 | Moos | :) |
00:01:33 | XavierGr | why ? |
00:01:41 | XavierGr | cause the optical in/out? |
00:01:59 | ]RowaN[ | i got a 30gig disk in my h120 now =] |
00:02:08 | muesli- | kewl |
00:02:11 | Moos | yes+radio+I don't look at minus divx... bacckliht... |
00:02:26 | Moos | I musiv lover |
00:02:33 | XavierGr | radio? |
00:02:44 | XavierGr | radio is better on H300 |
00:02:49 | Moos | and H140 is probably the best device for it, just it :) |
00:02:58 | Moos | music |
00:02:58 | muesli- | XavierGr really? |
00:03:12 | ]RowaN[ | with 30gigs of music... radio isnt something i care for hehe |
00:03:18 | Moos | +size :D |
00:03:26 | XavierGr | better... well I mean that it is meant to record without the little (very little) glitch |
00:03:26 | muesli- | size matters :D |
00:03:36 | muesli- | ah ok |
00:03:38 | *** | Saving seen data "./dancer.seen" |
00:03:40 | XavierGr | I agree I don't care about radio too. |
00:03:42 | ]RowaN[ | are h1xx, h3xx different physical sizes? |
00:03:50 | Moos | yes it is |
00:03:50 | XavierGr | I just mentioned it because Moos said it. |
00:03:55 | muesli- | you can compare h140 and 320 |
00:03:58 | ]RowaN[ | radio is kinda cool tho, like if u want to hear some news |
00:04:08 | muesli- | but the 340 is a brick stone |
00:04:24 | ]RowaN[ | h340 is fatter? |
00:04:27 | XavierGr | You have a nice colour screen and USBOTG though |
00:04:28 | muesli- | hell fat! |
00:04:35 | Moos | Xavier: yes I do the same just news or sport, for music my 40go collection :) |
00:04:44 | muesli- | but only usb1.1 |
00:04:48 | muesli- | not very helpful |
00:05:01 | Moos | when the backlight turn of the screen apear very horrible for me |
00:05:03 | XavierGr | Well if you have a 128mb flash card... |
00:05:04 | ]RowaN[ | 3xx only has only usb1.1 ??? |
00:05:15 | XavierGr | on USBOTG |
00:05:18 | muesli- | the usb2go port yes |
00:05:19 | ]RowaN[ | oh |
00:05:48 | koniu_ | which totally sucks btw - dumping 512mb card takes forever |
00:05:57 | muesli- | yepp |
00:06:04 | muesli- | guess would last ages |
00:06:17 | ]RowaN[ | i wonder if iriver will ever make another decent mp3 player hehe |
00:06:25 | muesli- | hehe |
00:06:39 | muesli- | damn..have to go..g'night mates |
00:06:47 | Moos | good night |
00:06:48 | ]RowaN[ | seeja |
00:07:41 | XavierGr | bye |
00:07:47 | ]RowaN[ | dont 4get to write |
00:07:51 | XavierGr | good night from me too later all. |
00:07:58 | XavierGr | what? |
00:08:08 | Moos | g'night too :) |
00:08:31 | ]RowaN[ | http://cgi.ebay.co.uk/iSkin-iriver-H100-H110-H120-H115-silicone-case-skin_W0QQitemZ5803633430QQcategoryZ86539QQrdZ1QQcmdZViewItem |
00:08:33 | ]RowaN[ | HOW much!! |
00:09:12 | Moos | Bagder: are you here? |
00:09:15 | ]RowaN[ | woo proper usb charger for iriver http://cgi.ebay.co.uk/iRiver-USB-charger-cable-PMP-iHP-120-140-H120-H140_W0QQitemZ5804448268QQcategoryZ48683QQrdZ1QQcmdZViewItem |
00:09:19 | ]RowaN[ | didnt know u could get them |
00:10:51 | | Quit lameD ("CGI:IRC (Ping timeout)") |
00:21:06 | | Join Speedforneed [0] (n=Blake@c-66-41-251-246.hsd1.mn.comcast.net) |
00:21:36 | | Join mrelwood [0] (n=54e7a54f@labb.contactor.se) |
00:21:57 | mrelwood | rockbox is finding it's place with iRiver! Cool! |
00:22:54 | Speedforneed | Anyone having a problem with the Sept. 2 build of the iRiver 120 port when it comes to WPS with bmps? |
00:23:35 | mrelwood | what means "boot" and "sim" versions on the bleeding edge download page? |
00:24:26 | | Nick Aison`zappelig is now known as Aison (n=hans@zux166-181.adsl.green.ch) |
00:24:31 | dpassen1 | Speedforneed: the syntax for bmp WPS has changed |
00:25:11 | Speedforneed | I know. |
00:25:22 | Speedforneed | I fixed all the ones I had, but no graphics show. |
00:25:26 | | Quit muesli- (Read error: 113 (No route to host)) |
00:25:40 | Speedforneed | I was looking at the CustomWPS page. |
00:27:07 | | Quit dpassen1 () |
00:27:10 | Speedforneed | No BMPs work at all. |
00:28:31 | | Quit TCK- (Read error: 110 (Connection timed out)) |
00:28:38 | Speedforneed | When it says that the filename of the WPS can't be more than 24 characters, does that include the directory path too? |
00:31:09 | ]RowaN[ | speed yeah my bmps stopped working from these new builds, but it was just the syntax i had to update in my wps |
00:37:37 | | Quit XavierGr (Read error: 113 (No route to host)) |
00:41:39 | | Join sango [0] (n=sango@c-24-30-72-152.hsd1.ga.comcast.net) |
00:41:39 | | Quit sango (Client Quit) |
00:42:24 | | Join sango [0] (n=sango@c-24-30-72-152.hsd1.ga.comcast.net) |
00:43:24 | | Quit sango (Client Quit) |
00:43:38 | | Part Moos |
00:51:58 | | Quit koniu_ (Read error: 110 (Connection timed out)) |
00:55:13 | | Quit ender` (Read error: 110 (Connection timed out)) |
00:56:04 | | Nick paugh is now known as AliasCoffee (n=pete@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
01:00 |
01:00:32 | | Quit Zagor (Client Quit) |
01:10:05 | | Quit Aison () |
01:11:14 | | Join kurzhaarrocker [0] (n=none@dsl-084-061-012-081.arcor-ip.net) |
01:19:20 | | Join Wy [0] (n=wy@c-24-18-62-209.hsd1.wa.comcast.net) |
01:19:49 | Wy | hey, anyone alive? |
01:20:50 | | Quit matsl (Remote closed the connection) |
01:33:28 | | Join TCK [0] (i=TCK@85-210-5-144.dsl.pipex.com) |
01:34:18 | | Quit gromit` (Remote closed the connection) |
01:36:36 | | Join solex_ [0] (n=jrschulz@c204048.adsl.hansenet.de) |
01:50:44 | | Quit solex (Read error: 110 (Connection timed out)) |
01:54:23 | | Join ashridah [0] (i=ashridah@220-253-120-199.VIC.netspace.net.au) |
02:00 |
02:03:42 | *** | Saving seen data "./dancer.seen" |
02:09:58 | | Join Liehbeth [0] (n=negk@adsl-34-224-114.asm.bellsouth.net) |
02:09:58 | | Quit mrelwood ("CGI:IRC (EOF)") |
02:31:53 | kurzhaarrocker | Does anybody here know what the return value of main_menu means? |
02:32:03 | | Part Liehbeth |
02:43:49 | | Quit preglow ("leaving") |
02:45:34 | kurzhaarrocker | In wps.c, line 650 the function wps_show() returns true even though the return value is declared as long. Is that the intension or just an old relict? |
03:00 |
03:07:32 | | Quit ashridah (Read error: 110 (Connection timed out)) |
03:09:02 | | Quit AliasCoffee ("Leaving") |
03:10:45 | | Quit kurzhaarrocker (Read error: 110 (Connection timed out)) |
03:40:47 | | Join ashridah [0] (i=ashridah@220-253-120-92.VIC.netspace.net.au) |
03:44:27 | Wy | Does anyone know where the flash for the jukebox recorder is? Linky on the site is broken :( |
03:55:26 | | Join paugh [0] (n=pete@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
03:56:37 | | Quit paugh (Client Quit) |
03:57:51 | | Nick ashridah is now known as Lost-ash (i=ashridah@220-253-120-92.VIC.netspace.net.au) |
04:00 |
04:03:43 | *** | Saving seen data "./dancer.seen" |
04:04:51 | | Quit merbanan ("Leaving") |
04:06:11 | | Join QT [0] (i=as@madwifi/users/area51) |
04:12:11 | | Quit cYmen ("zZz") |
04:17:23 | | Quit QT_ (Read error: 110 (Connection timed out)) |
04:28:49 | | Quit tvelocity (Read error: 113 (No route to host)) |
04:46:32 | | Join random_man [0] (n=cfe6dab1@labb.contactor.se) |
04:56:24 | | Quit random_man ("CGI:IRC") |
05:00 |
05:13:42 | | Join bagawk [0] (i=1000@unaffiliated/bagawk) |
05:15:54 | | Join tvelocity [0] (n=tony@ipa175.1.tellas.gr) |
05:16:26 | | Quit bagawk (Client Quit) |
05:32:28 | | Nick Lost-ash is now known as ashridah (i=ashridah@220-253-120-92.VIC.netspace.net.au) |
06:00 |
06:03:45 | *** | Saving seen data "./dancer.seen" |
06:35:02 | | Quit webguest97 ("CGI:IRC (EOF)") |
06:50:31 | | Join DMJC [0] (n=DMJC-L@220-244-239-235-sa-pppoe.tpgi.com.au) |
07:00 |
07:23:01 | | Quit DMJC (Read error: 110 (Connection timed out)) |
07:27:29 | | Join Paul_The_Nerd [0] (n=paulthen@cpe-66-68-93-2.austin.res.rr.com) |
07:37:52 | | Quit ansivirus (Remote closed the connection) |
07:44:30 | | Join ansivirus [0] (n=ansiviru@adsl-68-88-64-228.dsl.rcsntx.swbell.net) |
08:00 |
08:03:48 | *** | Saving seen data "./dancer.seen" |
08:15:16 | | Join knoppix [0] (n=none@dsl-084-061-009-121.arcor-ip.net) |
08:29:38 | | Quit Paul_The_Nerd ("Chatzilla 0.9.68a [Firefox 1.0.6/20050716]") |
08:42:15 | | Quit thegeek (Read error: 110 (Connection timed out)) |
09:00 |
09:09:24 | | Quit tvelocity ("Leaving") |
09:19:39 | | Join tvelocity [0] (n=tony@ipa175.1.tellas.gr) |
09:26:42 | amiconn | morning |
09:26:51 | knoppix | moin |
09:27:09 | Speedforneed | That's funny, cause I have yet to go to bed. |
09:27:27 | knoppix | here in good old germany its half past ten in the morning |
09:27:38 | Speedforneed | 2:27am here. |
09:27:59 | Speedforneed | I == dead. |
09:29:05 | * | amiconn is in germany too |
09:29:12 | knoppix | amiconn: do you kow the meaning of the return values of the boolean value the menus return? e.g. the retval of main_menu() |
09:29:13 | tvelocity | morning |
09:29:51 | amiconn | knoppix: Yes, they return true when they leave because they detected an USB connection |
09:29:53 | | Join HCl_ [0] (i=hcl@2001:610:1908:8000:290:27ff:feca:8029) |
09:30:22 | knoppix | hm. I'll probably abuse that mechanism then |
09:31:02 | amiconn | See menu.c, lines 402ff |
09:31:24 | | Quit HCl (Read error: 104 (Connection reset by peer)) |
09:32:20 | knoppix | So all the function that are called within a menu have to return true when they were in usb mode. |
09:33:26 | knoppix | (that's what I conclude from the default case in the function you mentioned) |
09:33:57 | knoppix | What I want to do: When the user quits the recording screen with the on button rockbox shall play the new recording instantly. |
09:35:02 | knoppix | unfortunately rockbox usually returns to the menu after the recording screen. |
09:35:25 | | Quit ashridah ("Leaving") |
09:35:38 | | Join ashridah [0] (i=ashridah@220-253-120-92.VIC.netspace.net.au) |
09:37:14 | knoppix | So I abuse the usb mode only to make rockbox skip the menu (and eventually the wps too) and return straight to tree. There I want to start playback of the new recording. |
09:37:53 | | Nick knoppix is now known as kurzhaarrocker (n=none@dsl-084-061-009-121.arcor-ip.net) |
09:38:27 | | Join LaMeD [0] (n=55406621@labb.contactor.se) |
09:38:52 | LaMeD | hello (and good morning to some) |
09:39:02 | * | kurzhaarrocker bows |
09:39:19 | LaMeD | a question: disk spindown means lowering the speed or stopping it at all? |
09:39:46 | kurzhaarrocker | The disk stops spinning |
09:40:26 | LaMeD | Yes! thank you. I knew my translation was more correct |
09:42:17 | amiconn | kurzhaarrocker: Imho it could be useful to extended the menu system's return values to be more flexible |
09:43:40 | amiconn | Afaiu the reason for having the return value is to let the tree know that there was usb, so the file system contents may have changed and needs to be re-read |
09:44:52 | kurzhaarrocker | I was in doubt wether it means "was in usb" or "file system changed" |
09:45:08 | LaMeD | here's another one. why would in the previous version rockbox has asked "is battery low?" if saved settings has faild on recorder, and now it asks "no partition?" |
09:45:16 | amiconn | The plugins do the same, and some of them (which create files) mis-use the "was in usb" return value |
09:47:32 | amiconn | LaMeD: This is historic; originally it was thought that the most likely cause for save settings failing would be low battery |
09:47:35 | | Join Xanthos [0] (n=xanthosj@user-0c6trgi.cable.mindspring.com) |
09:48:01 | Xanthos | Wow, full channel, anyone at keyboard? |
09:49:12 | solex_ | hm? |
09:49:33 | Xanthos | Hey, I need some help with an ifp player |
09:49:43 | Xanthos | Windows ate it |
09:50:21 | * | Xanthos offers free cookies :) |
09:50:58 | solex_ | ifp == iriver? |
09:51:01 | Xanthos | yeah |
09:51:16 | solex_ | disk broken? |
09:51:20 | Xanthos | It's an old on |
09:52:22 | Xanthos | kind of, it's the ifp100 series I've running firmware to make it a UMS and it works find, but XP crapped on the drive and when I tried to reformat it it failed |
09:52:47 | Xanthos | Now the format is corrupt so I can't stick a hex file on it to flash the firmware |
09:52:52 | Xanthos | :-/ |
09:53:16 | solex_ | Have you tried repartitioning it? |
09:53:22 | Xanthos | thought about it |
09:53:36 | Xanthos | is there a hidden partition that stores all the iriver crap? |
09:53:49 | Xanthos | was afraid of wiping that out |
09:54:04 | solex_ | no, there is none (at least not on my h120 |
09:54:07 | solex_ | ) |
09:54:23 | Xanthos | disk manager isn't giving me an option to delete the partition |
09:55:14 | Xanthos | shows a 250meg healthy FAT partition (XP's not too swift is it) |
09:55:51 | solex_ | whatever it means with "healthy" |
09:55:55 | Xanthos | lol |
09:56:14 | solex_ | and you really cannot delete it? |
09:56:23 | solex_ | in other words: you know where the entry should be |
09:56:23 | Xanthos | any drive that's been attached to an XP os CAN'T be healthy |
09:56:40 | Xanthos | yeah, unless it's somewhere different for removable drives |
09:56:41 | solex_ | Well, try Knoppix ;) |
09:57:30 | Xanthos | is it bootable? |
09:57:43 | Xanthos | I mean, without a hard drive |
09:58:16 | solex_ | Knoppix is a bootable Linux-CD-ROM |
09:58:24 | solex_ | or even a DVD |
09:58:27 | Xanthos | lyke could I burn an iso and boot, format the piece of crap and then be happy? |
09:58:29 | Xanthos | cool |
09:58:40 | solex_ | yep |
09:58:54 | Xanthos | think it would see the usb ok without windows 500megs of drivers? |
09:59:33 | solex_ | Knoppix? Sure. USB Mass Storage support is in all recent kernels. |
09:59:51 | Xanthos | I need to learn linux anyway, I'm so friggin sick of M$ I could puke |
10:00 |
10:00:50 | solex_ | if you've got the bandwidth: |
10:00:50 | solex_ | http://torrent.unix-ag.uni-kl.de/ |
10:01:06 | Xanthos | so does linux support all the file formats? FAT/16/32 NTFS ? |
10:01:19 | solex_ | NTFS is read-only in Linux |
10:01:28 | solex_ | but all the FAT formats are fine |
10:01:54 | Xanthos | that's cool, NTFS in "what? where, I don't see another disk there" in DOS |
10:02:16 | Xanthos | cool, torrents :) |
10:02:46 | solex_ | if it's too slow: |
10:02:50 | solex_ | knoppix-mirrors/">http://www.knopper.net/knoppix-mirrors/ |
10:03:18 | solex_ | are you behind a router with dhcp? |
10:03:37 | Xanthos | yeah |
10:03:49 | *** | Saving seen data "./dancer.seen" |
10:03:55 | Xanthos | linksys |
10:04:02 | solex_ | wifi? |
10:04:07 | Xanthos | no |
10:04:25 | solex_ | good. then you will probably have an internet connection when running knoppix |
10:04:32 | solex_ | there should be an irc client as well |
10:04:41 | Xanthos | these are all dutch? |
10:04:55 | Xanthos | or is that german |
10:05:06 | solex_ | there is a german and an english version |
10:05:24 | Xanthos | is 4.0 available on cd? |
10:05:45 | solex_ | I don't think so, but I am not sure |
10:05:58 | Xanthos | oh duh, -EN and -DE isn't a dead giveaway on the lang |
10:06:02 | solex_ | 3.9 is still fine |
10:07:10 | solex_ | when you boot from the cd, there will be a menu at the beginning |
10:07:34 | LaMeD | amiconn, are you there? |
10:07:40 | solex_ | you have to press f1 or f2 to show some options |
10:07:53 | solex_ | there you can select another keyboard layout |
10:08:01 | solex_ | in case you don't want german or english |
10:08:17 | Xanthos | cool |
10:08:42 | Xanthos | so it doesn't need any writable media at all to run? |
10:08:43 | amiconn | LaMeD: yup |
10:09:08 | Xanthos | this would kick @$$ for a server box |
10:09:22 | Maxime | maybe but you can't write settings anywhere.. |
10:09:39 | Maxime | so, when you reboot you have to reconfigure all |
10:10:07 | Xanthos | I'll just use my 2 gig dos partition and store whatever it needs |
10:10:18 | Xanthos | dos is kidna useless now anyway |
10:11:19 | Xanthos | anyway, why do you think i wouldn't be able to delete the fat part on the iriver? |
10:11:40 | | Quit tvelocity ("Leaving") |
10:13:30 | solex_ | Xanthos: no, Knoppix doesn't need write access to any disks |
10:13:48 | solex_ | but I have no idea, why windows doesn't allow you do delete the partition |
10:14:46 | Xanthos | man, that's a sweet torrent, I'm getting like 650kB a second |
10:18:04 | * | solex_ grumbles |
10:19:28 | * | Xanthos wonders if there's a way to flash the firmware from another drive |
10:19:30 | Xanthos | ? |
10:20:07 | | Join gromit` [0] (n=gromit`@ras75-5-82-234-244-69.fbx.proxad.net) |
10:20:09 | solex_ | what exactly do you mean? |
10:20:25 | solex_ | the iriver firmware isn't on the hard disk, as far as i know. |
10:20:46 | Xanthos | like, you have to have the .hex on the ums and flash from the menu in the device... |
10:21:13 | Xanthos | but since the file system is corrupt I can't put the hex on the drive |
10:22:31 | solex_ | I think the path to the hex file is hardwired into the original firmware, so i suspect the answer is 'no' |
10:23:26 | Xanthos | crappy |
10:23:40 | Xanthos | and I think the firmware files are encrypted too |
10:25:08 | Xanthos | ok, but the original wasn't ums... if there's anything permanent in the device there should be a way to get to it right? |
10:25:27 | Xanthos | I tried flashing an empty .hex tho... no good |
10:26:22 | solex_ | btw, what is this "ums" stuff exactly? |
10:26:33 | Xanthos | I've got a regular jump drive here, I can delete the partition on it... |
10:26:39 | Xanthos | mass storage device |
10:26:45 | Xanthos | not sure |
10:27:57 | Xanthos | both are seen as standard disk drives |
10:28:04 | solex_ | hm. |
10:28:27 | Xanthos | I'm thinking the only thing that could stop me deleting the partition is the driver, but it's a microsoft deal driver |
10:28:40 | solex_ | ACK |
10:28:56 | solex_ | another "feature" to protect you from yourself, I guess |
10:29:05 | Xanthos | LOL |
10:29:23 | solex_ | linux allows everyone to shoot their feet as often as they want |
10:29:28 | Xanthos | ok, I see one difference, it sees the iriver as a removable and the regular as a "basic" |
10:29:46 | solex_ | which one is which? |
10:29:51 | Xanthos | regular usb jump drive |
10:30:04 | solex_ | sorry, parse error on my side |
10:30:15 | Xanthos | the iriver is seen as removable |
10:30:16 | LaMeD | cvs -z3 -d:pserver:anonymous@rockbox.haxx.se:/cvsroot/rockbox-devel co rockbox < why is this wrong? |
10:30:26 | solex_ | well, the iriver *is* removable and your other hard disks are probably not. |
10:30:47 | LaMeD | ":no such repository" |
10:30:50 | Xanthos | no, I'm comparing it to a usb jump drive |
10:31:04 | solex_ | oh |
10:31:38 | solex_ | and you (principally) could repartition the "basic" disks? |
10:31:42 | Xanthos | hmm, it doesn't have a logical drive letter in the properties... how is that possible |
10:32:09 | solex_ | I suspect your ifp is not a regular mass storage device... |
10:32:17 | Xanthos | hehe |
10:32:18 | amiconn | LaMeD: cvs -z3 -d:pserver:anonymous@rockbox.haxx.se:/cvsroot/rockbox co rockbox-devel |
10:32:23 | solex_ | ...which would mean, you're out of luck with knoppix |
10:32:29 | Xanthos | it has no volume label either |
10:32:40 | solex_ | but it's in the explorer? |
10:32:43 | Xanthos | but it does... |
10:32:50 | Xanthos | yeah, it has a letter and label in explorer |
10:32:56 | solex_ | Sounds like the behaviour of my mobile phone |
10:33:17 | Xanthos | erm, well it did lol maybe since I forgot I'm formatting it right now |
10:33:18 | Xanthos | lol |
10:33:30 | solex_ | huh? |
10:33:46 | Xanthos | it's being formatted right now, probably why it's unmounted :) |
10:33:57 | LaMeD | Amiconn, thanks. could you answer me in private window? |
10:34:01 | solex_ | what are you formatting? |
10:34:07 | Xanthos | the iriver, again |
10:34:16 | solex_ | %) |
10:34:37 | Xanthos | this sucks |
10:36:06 | Xanthos | ok, you can flash an optical drive with an exe and a hex file... couldn't you do that to a usb drive? |
10:37:11 | solex_ | I think it depends on what the device supports |
10:37:47 | Xanthos | oh |
10:38:07 | Xanthos | nero burns bootable roms right? |
10:38:14 | solex_ | yep |
10:38:17 | Xanthos | k |
10:38:52 | solex_ | don't burn too fast, you'd overtake me. :) |
10:38:59 | * | solex_ is burning 4.2x |
10:41:07 | solex_ | um, xanthos? |
10:41:19 | solex_ | my iriver h120 has a menu option for formatting |
10:41:28 | solex_ | menu -> general -> format |
10:43:39 | solex_ | what about yours? |
10:43:42 | kurzhaarrocker | a c question: I defined a variable outside of any function "static char path_buffer[MAX_PATH];" From a function within that file I want to "return path_buffer;" That should work, shouldn't it? |
10:43:46 | Xanthos | yeah, I looked for that, not in this one :) |
10:45:21 | | Join ender` [0] (i=ychat@tm.213.143.74.124.dc.telemach.net) |
10:45:37 | solex_ | would have been too easy |
10:46:21 | Xanthos | lol |
10:46:23 | Xanthos | yeah |
10:47:14 | LaMeD | sorry for being so lame... how do I send a staffer |
10:47:14 | LaMeD | ? |
10:47:53 | kurzhaarrocker | argh, I mixed up a function variable with a global variable. grrr. |
10:48:04 | LaMeD | NM! |
10:48:24 | | Quit LaMeD ("CGI:IRC (EOF)") |
10:48:55 | Xanthos | now all your variables will be globally non-functional... OMG you just wrote WinXP |
10:49:05 | | Join Lshachar [0] (n=55406621@labb.contactor.se) |
10:53:36 | Lshachar | 1 |
10:53:56 | * | solex_ is preparing breakfast |
10:54:08 | * | kurzhaarrocker steals solex_ a toast |
10:54:23 | Xanthos | OMGOMG |
10:54:25 | Xanthos | I think I did it |
10:54:26 | Xanthos | lol |
10:55:17 | solex_ | what? |
10:55:19 | Xanthos | I told it to mount it as if it were a 5 1/4 disk, and I have the irq and i/o for that drive disabled in bios, so it HAD to format it like a real volume |
10:55:31 | Xanthos | it's a 250 meg floppy disk now |
10:55:42 | solex_ | on 5"1/4 |
10:55:48 | Xanthos | lol yeah |
10:55:51 | solex_ | nice! be sure not to bend it! |
10:55:54 | Xanthos | lmao |
10:56:24 | Xanthos | well, if it works, at least I got a bootable copy of linux now :) |
10:58:27 | Xanthos | woohoo! firmware is upgrading yay Thanks for your brainstorming help man |
10:58:36 | solex_ | you're welcome |
10:58:59 | solex_ | but you should really try knoppix, it's quite impressive what they get on a single cd |
10:59:15 | Xanthos | hehe, I was already checking prices on the H series I may get one anyway... I just love this little triangle tho |
10:59:29 | Xanthos | Yeah, I've got it in the drive, gonna check it out next time I reboot |
10:59:52 | Lshachar | . |
11:00 |
11:00:03 | Xanthos | gotta do some BF2 now tho... lol I was getting my mp3's together to play Batlefield like... 6 hours ago when Winblows decided to urinate on my player |
11:00:11 | | Join tvelocity [0] (n=tony@ipa175.1.tellas.gr) |
11:00:12 | kurzhaarrocker | Has anybody tried to use knoppix (dvd) as development environment for rockbox? |
11:00:57 | solex_ | kurzhaarrocker: no. you would need some place to write |
11:01:24 | solex_ | so you can as well go ahead and install any flavour of linux |
11:01:25 | kurzhaarrocker | you can mount hd easily |
11:01:26 | | Join bluebrother^ [0] (n=c28@nat-ph3-wh.rz.uni-karlsruhe.de) |
11:01:42 | Xanthos | is rockbox an os or a media manager? |
11:01:53 | kurzhaarrocker | or use an usb stick or even the jukebox itself as storage for your home dir |
11:04:01 | kurzhaarrocker | I haven't managed to build the cross compiler on knoppix yet, but I didn't try very hard. |
11:05:40 | solex_ | Xanthos: an os |
11:05:59 | solex_ | but it lives on the harddisk |
11:06:04 | solex_ | unlike the iriver firmware |
11:06:13 | solex_ | that way you can dual-boot |
11:09:42 | Xanthos | cool |
11:10:16 | Xanthos | what are the advantages of it over other os's? it's small? |
11:10:36 | | Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
11:11:06 | solex_ | http://www.rockbox.org/docs/features.html |
11:11:41 | kurzhaarrocker | rockbox is a open source firmware replacement for portable mp3 players |
11:13:18 | kurzhaarrocker | It doesn't really make much sense to think of it as an os, its more. |
11:14:04 | solex_ | imo, rockbox's best features are the customizable wps and on-the-fly playlists |
11:14:22 | Xanthos | wow guess I can't use it tho, at least till I buy a player with an actual hard drive |
11:14:46 | | Nick HCl_ is now known as HCl (i=hcl@2001:610:1908:8000:290:27ff:feca:8029) |
11:15:20 | Xanthos | this one's just 250 meg flash memory |
11:15:21 | kurzhaarrocker | Only a few hand selected players are supported. See http://rockbox.org The very first sentence :) |
11:15:55 | kurzhaarrocker | And the ondi players are flash based, without hd ... |
11:16:43 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
11:17:27 | Xanthos | man, that sounds awsome... I've gotta keep rockbox in mind when I pick which player I'm gonna buy then |
11:17:55 | solex_ | i can recommend the old h1x0 series |
11:18:01 | * | kurzhaarrocker wonders how Xanthos found this channel without knowing what rockbox is about. |
11:18:10 | solex_ | i bought one only a few weeks ago |
11:18:54 | Xanthos | lol |
11:19:04 | * | solex_ too |
11:19:06 | Xanthos | there's a few blogs on it |
11:19:51 | Xanthos | I was planning on using rockbox to flash my firmware then I saw the irc channel on the site and came here first (before finishing reading the site) :) |
11:20:18 | kurzhaarrocker | ... including the first sentence :) ... |
11:20:32 | Xanthos | lol |
11:20:34 | Xanthos | :) |
11:21:13 | Xanthos | well actually I noticed my player wasn't supported which isn't anything new for me since it's like one of the first made lol |
11:21:32 | Lshachar | 123 |
11:22:34 | solex_ | does anybody know why rockboy is not part of the iriver builds? |
11:22:46 | Xanthos | ifp-190 doesn't get much attention from iRiver either, but judging from the fact that you guys have this wicked open source project going, I guess not many models get much attention from them |
11:22:50 | | Quit Febs (Read error: 104 (Connection reset by peer)) |
11:23:33 | | Join Febs [0] (n=Febs@207-172-122-81.c3-0.rdl-ubr4.trpr-rdl.pa.cable.rcn.com) |
11:24:35 | Lshachar | <Solex_> maybe one of those? |
11:24:37 | Lshachar | We have a few other convenient aliases that gets several modules at once for you: |
11:24:37 | Lshachar | rockbox - gets everything you need to compile and build rockbox for target |
11:24:37 | Lshachar | rockbox-devel - like 'rockbox' but also includes simulators and gdb code |
11:24:37 | DBUG | Enqueued KICK Lshachar |
11:24:37 | Lshachar | rockbox-all - gets everything there is in CVS, all modules |
11:24:37 | Lshachar | website - gets the www and docs modules |
11:26:12 | Lshachar | it's present in the Devel package. i've just checked. |
11:26:38 | solex_ | hm, that might be a reason to set up a devel-environment... |
11:26:44 | | Join webguest06 [0] (n=55406621@labb.contactor.se) |
11:26:49 | webguest06 | lshachar 123 |
11:27:47 | | Quit webguest06 (Client Quit) |
11:29:00 | kurzhaarrocker | those irivers don't feature digital in, do they? |
11:29:10 | amiconn | They do |
11:29:14 | amiconn | (H1x0) |
11:29:20 | amiconn | optical in, optical out |
11:29:37 | HCl | h3x0 doesn't |
11:29:40 | HCl | but h1x0 does |
11:29:42 | amiconn | http://www.rockbox.org/twiki/bin/view/Main/DeviceChart#iriver_units |
11:29:44 | HCl | gmorning |
11:29:47 | Xanthos | what's the max disk size on the new irivers? |
11:29:57 | kurzhaarrocker | ah, thanx, amiconn |
11:31:04 | HCl | h3x0? |
11:31:13 | HCl | i think 40gb, but last time i checked they're upgradable |
11:31:20 | Xanthos | cool |
11:31:45 | Xanthos | are they using a third party for the drives? (like western digital) |
11:32:41 | HCl | mst upgradable mods are done by users |
11:32:49 | HCl | not supported by iriver themselves |
11:33:16 | Xanthos | but there's space in them for an industry standard thumb drive? |
11:33:38 | HCl | i'm not sure what you mean with thumb drive |
11:33:44 | HCl | the iriver uses 1.8" drives |
11:34:18 | Xanthos | that's probably not the right word.. I don't know much about recent hardware, havn't been keeping up with it |
11:34:54 | Xanthos | but they're like an industry standard tho right? not something proprietary to Iriver |
11:35:31 | HCl | yes |
11:35:34 | HCl | they are |
11:35:52 | Xanthos | man, I gotta get a player |
11:36:16 | Xanthos | you know what kind of ram they're using in them? |
11:36:26 | HCl | not really |
11:36:46 | Xanthos | probably all soldered in anyway |
11:37:25 | Xanthos | but you could really mod the crap out of them if you could get the parts |
11:37:40 | HCl | i guess. irivers have 32mb of ram by default |
11:37:52 | HCl | i can't really see how having more would help |
11:38:23 | Xanthos | well, if they have a decent processor in them, you'd could make it closer to a pda than a portable player |
11:38:43 | HCl | the cpu in it is only a coldfire 140mhz |
11:38:50 | Xanthos | oh |
11:38:51 | HCl | running at 120mhz max |
11:38:52 | Xanthos | heh |
11:39:07 | Xanthos | guess they wouldn't need much more for audio processing |
11:39:16 | HCl | mhm |
11:39:39 | solex_ | Xanthos: and for a pda you would need a decent keyboard |
11:39:47 | Xanthos | true |
11:40:02 | Xanthos | or a touch screen |
11:40:04 | HCl | for a pda, i just use my pda, lol. |
11:40:09 | Xanthos | LOL |
11:40:15 | Xanthos | good point |
11:40:26 | solex_ | maybe someone could hack in a touchscreen... :) |
11:40:39 | Xanthos | sounds kind of expensive :) |
11:40:49 | Xanthos | I need an lcd for my laptop |
11:41:04 | Xanthos | turns out HP's are incompatible with asphalt |
11:41:15 | HCl | asphalt? |
11:41:19 | Xanthos | lol |
11:41:26 | kurzhaarrocker | plug'n break |
11:41:33 | HCl | gheh. |
11:41:55 | Xanthos | yeah dam samsonite suitcase is to blame tho... told it to stay and it rolled |
11:42:12 | Xanthos | that or the screen wasn't strong enough, I just know I'm not to blame :P |
11:42:50 | HCl | mhm |
11:43:49 | Xanthos | multi-handicapped mainstream? |
11:45:18 | Xanthos | video playback with sound? awsome |
11:48:02 | kurzhaarrocker | on the archos it's a funny gimmick. It works but you can't really watch movies on 112x64 pixel. |
11:48:13 | Xanthos | omfh... 8 minutes to transfer 150 megs, I really do need a new player |
11:48:23 | HCl | again something for which i use my pda... heh.. |
11:48:36 | HCl | divx 320x240 16bits color.. |
11:48:39 | Xanthos | lol it's a cool feature to have tho |
11:48:48 | HCl | i dunno |
11:48:57 | kurzhaarrocker | I use my mobile phone for that :) |
11:48:57 | HCl | some features i don't see the usage of |
11:49:02 | Xanthos | well if the screens get better, rockbox will be ready |
11:49:08 | HCl | but i guess other people have the same thing with features i add. |
11:49:23 | HCl | the problem is that though the h3x0 has a colorscreen |
11:49:28 | HCl | the cpu is still the same one |
11:49:34 | Xanthos | oh |
11:49:42 | HCl | people expect to get color playback and such and color gameboy on h3x0 |
11:49:44 | Xanthos | so more of a slide show than a video |
11:49:55 | HCl | but they fail to realize that the cpu isn't upgraded at all and still very slow |
11:50:18 | HCl | i believe the iriverfirmware actually had a decent framerate on h3x0 |
11:50:27 | amiconn | kurzhaarrocker: Believe me, you can watch movies. I did this back when playing around with the video plugin |
11:50:48 | amiconn | The white backlight mod is helpful... |
11:51:55 | amiconn | In general it's not really suited for watching movies, but for the occasional music video it is sufficient... |
11:52:00 | Xanthos | any news on the next series to come out? |
11:52:04 | kurzhaarrocker | yes you can watch them but can you really enjoy them? Don't get me wrong. I love that geek feature. |
11:52:56 | amiconn | At least the archos lcd is faster than the iriver H1x0 lcd |
11:53:02 | Xanthos | music video's might be something iriver has on the board |
11:54:05 | kurzhaarrocker | Xanthos: Info on the next version of rockbox: http://www.rockbox.org/twiki/bin/view/Main/ReleaseNotes |
11:55:41 | Xanthos | Cool, I was talking about the next series of players, but Rockbox looks like they're already thinking about the future |
11:57:28 | Xanthos | gonna go do some battlefield, I'll drop back in this channel for some advice b4 I buy my new player tho |
11:58:21 | | Quit Xanthos () |
11:59:04 | | Quit Lshachar ("CGI:IRC") |
12:00 |
12:02:24 | | Join webguest84 [0] (n=55406621@labb.contactor.se) |
12:02:32 | | Quit tvelocity (Read error: 104 (Connection reset by peer)) |
12:03:51 | *** | Saving seen data "./dancer.seen" |
12:05:50 | webguest84 | amiconn, I'm having difficulties... |
12:06:03 | webguest84 | few more minuts (lshachar) |
12:06:08 | | Quit webguest84 (Client Quit) |
12:06:26 | | Join Lshachar [0] (n=55406621@labb.contactor.se) |
12:06:30 | Lshachar | 1 |
12:06:39 | kurzhaarrocker | 2 |
12:06:56 | Lshachar | 3 |
12:07:04 | kurzhaarrocker | goto 1 |
12:07:08 | Lshachar | 2 |
12:07:26 | kurzhaarrocker | *stack overflow error* |
12:07:26 | Lshachar | loop until i = 25 |
12:07:31 | Lshachar | damn! |
12:07:54 | Lshachar | debug <kurzhaarrocker> |
12:08:07 | kurzhaarrocker | No soap please! |
12:08:16 | Lshachar | rofl |
12:09:40 | | Join webguest94 [0] (n=51429e1d@labb.contactor.se) |
12:10:01 | | Join Moos [0] (i=Moos@m29.net81-66-158.noos.fr) |
12:10:33 | Moos | Hello guys! |
12:10:43 | | Quit webguest94 (Client Quit) |
12:17:47 | Slasheri | hi :) |
12:23:07 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
12:23:07 | * | HCl yawns |
12:23:43 | * | kurzhaarrocker splashes a bucket of cold water over HCl to wake him up |
12:24:46 | HCl | mrf. |
12:24:48 | HCl | that doesn't work on me |
12:36:31 | Lshachar | DAAAMMMNNN..... alll thhat wastedd tiimmeee... |
12:41:23 | Lshachar | amiconn |
12:50:09 | | Join Mxm`Pas`Bien [0] (n=flemmard@fbx.flemmard.net) |
12:50:09 | | Quit Maxime (Read error: 104 (Connection reset by peer)) |
12:50:55 | | Nick Mxm`Pas`Bien is now known as Maxime (n=flemmard@fbx.flemmard.net) |
12:54:30 | | Quit kurzhaarrocker (Remote closed the connection) |
12:54:33 | | Join hicks [0] (n=hicks@zeus.mups.co.uk) |
13:00 |
13:01:42 | HCl | Lshachar: ? |
13:02:25 | solex_ | damn, my new wps file is 33 characters too big |
13:04:26 | | Join gulugulu [0] (n=HRCLITE6@85.97.181.29) |
13:04:30 | solex_ | is anyone here able/willing to increase the maximum wps file size? |
13:04:50 | solex_ | the new conditionals (esp. for codec) can become quite big |
13:04:59 | | Join hebele [0] (n=HRCLITE6@85.97.181.29) |
13:06:48 | hebele | hi yall I have a question. I know this is not your business but I have to ask it and u re my last chance. I need answers key of this test : sfl.erciyes.edu.tr/sample2.htm . I m a learner of English. Please help me :) |
13:07:48 | HCl | you won't learn english by cheating a test. |
13:08:25 | hebele | I did it but I dont have answers key of the test |
13:09:13 | hebele | pardon I made mistake sorry |
13:09:57 | hebele | I did it but I havent answers of the test. I hope this is true :) |
13:10:50 | hebele | can u help me. I suppose not. Thanx yall. Have a nice day |
13:11:00 | Lshachar | hcl yeah? |
13:11:32 | HCl | i was confused about what you meant with wasted time? |
13:11:38 | HCl | hebele: i can't even access that site |
13:11:42 | HCl | :/ |
13:12:21 | hebele | ! |
13:12:55 | Lshachar | hcl I wasn't identified and tried sending amiconn messages for half an houre |
13:13:03 | Lshachar | :/ |
13:13:20 | hebele | strange |
13:13:31 | hebele | anyway thx have a nice day |
13:13:50 | | Part hebele |
13:17:19 | HCl | ah |
13:17:21 | HCl | :X |
13:23:33 | | Quit gulugulu (Read error: 110 (Connection timed out)) |
13:26:01 | | Part t0mas |
13:26:01 | | Join t0mas [0] (n=Tomas@unaffiliated/t0mas) |
13:26:05 | t0mas | woops |
13:26:25 | Mode | "#RockBox +o t0mas " by ChanServ (ChanServ@services.) |
13:26:29 | Mode | "#RockBox -o t0mas " by t0mas (n=Tomas@unaffiliated/t0mas) |
13:26:31 | t0mas | ok, works |
13:26:47 | t0mas | is some-one with an archos device around? |
13:26:56 | t0mas | This: |
13:26:56 | t0mas | id: LANG_F2_MODE |
13:26:56 | t0mas | desc: in wps F2 pressed |
13:26:56 | DBUG | Enqueued KICK t0mas |
13:26:56 | t0mas | eng: "Mode:" |
13:27:01 | t0mas | in the language file... |
13:27:05 | t0mas | what "mode" is that? |
13:27:11 | t0mas | Playback mode? |
13:33:15 | Lshachar | I don't have time right now to build an archos sim, but on the iriver (which is very similar in that menu ) a long click on the a-b button - the string "mode:" appears twice: shuffle mode and repeat mode. this is very similar in archos. |
13:33:32 | | Join Paul_The_Nerd [0] (n=paulthen@cpe-66-68-93-2.austin.res.rr.com) |
13:34:38 | | Quit Paul_The_Nerd (Client Quit) |
13:36:05 | t0mas | jup |
13:36:09 | t0mas | I've build an archos sim |
13:36:17 | t0mas | it's playback mode |
13:36:22 | | Join tvelocity [0] (n=tony@ipa175.1.tellas.gr) |
13:39:18 | | Join Lear [0] (n=chatzill@h179n2c1o285.bredband.skanova.com) |
13:39:46 | Lear | Anyone else with simulator build problems? |
13:39:58 | t0mas | wich one? |
13:39:59 | t0mas | iriver? |
13:40:01 | t0mas | archos? |
13:40:36 | Lear | iriver, though I wonder if that matters... |
13:40:48 | t0mas | well... I just did an archos build, and it worked |
13:40:57 | t0mas | doing Iriver now |
13:41:50 | t0mas | error's in dsp.c ? |
13:41:54 | Lear | It works fine until GENLANG, then I only get the following message: gcc: 1: No such file or directory |
13:41:58 | Lear | Not very helpful... |
13:42:27 | t0mas | no... not really... |
13:42:36 | t0mas | check apps/lang |
13:42:41 | t0mas | are the .lang files there? |
13:42:46 | t0mas | and have you done make in tools? |
13:42:58 | Lear | Sure is, I mean, lang.c is generated properly... |
13:43:32 | t0mas | no, in the apps/lang directory... are the files there? |
13:43:40 | t0mas | and have you run make in the toold dir? |
13:43:42 | t0mas | *tools |
13:43:50 | | Quit Lshachar ("CGI:IRC") |
13:44:07 | Lear | I have tools; did a target build yesterday... |
13:44:18 | t0mas | ok |
13:44:20 | t0mas | weird |
13:46:58 | Lear | Seems like it is one of the defines on the command line; I removed them, then it worked... |
13:48:10 | Lear | Hm.. -DIRIVER_H120 1 lacks an equal sign. tools/configure time I guess... |
13:48:49 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
13:48:53 | t0mas | ah, can you try if it works with a clean checkout? |
13:49:27 | Slasheri | Lear: make clean and reconfigure |
13:49:28 | Lear | lets try the re-configure first... |
13:49:35 | Slasheri | then it works |
13:50:41 | Lear | Ah, yes, that "broken sim build" commit... |
13:56:59 | solex_ | for those interestet: i finished my wps with a custom status bar |
13:57:13 | solex_ | it uses images for play status, repeat mode and codec: |
13:57:14 | solex_ | http://www.rockbox.org/twiki/bin/view/Main/WpsGallery#Update_ |
13:57:20 | solex_ | *interested |
13:58:08 | solex_ | it's just a pity that i hit the maximum file size limit for the wps |
13:58:24 | solex_ | the declaration for the codec bitmaps is a little bit greedy |
13:59:06 | amiconn | Slasheri: Your updated finnish.lang has some problems. |
13:59:47 | amiconn | (1) it contains many of the ### todo comments. These are supposed to be removed when done, not to be committed |
14:00 |
14:00:32 | amiconn | (2) The deprecations aren't done |
14:01:22 | Lear | Filesize could be increased a bit on iriver, I guess.. But shouldn't one of the images read "VBR"? |
14:01:54 | | Join Zagor [0] (i=foobar@pdpc/supporter/sustaining/Zagor) |
14:03:05 | t0mas | hi |
14:03:55 | *** | Saving seen data "./dancer.seen" |
14:03:55 | amiconn | Imho it would be useful to support bitmap clipping, especially since we have conditional image support. |
14:04:23 | amiconn | Currently you have to use one .bmp per image, not very practical if you want to have dozens of them |
14:04:45 | amiconn | With clipping support, all images used in a .wps design could reside in one .bmp file |
14:07:11 | solex_ | amiconn: how does it work? is it like a gif file with several images inside? |
14:07:17 | t0mas | no.. |
14:07:20 | t0mas | it's 1 bmp file |
14:07:28 | t0mas | containing all images next to eachother |
14:07:38 | t0mas | *each other |
14:07:59 | t0mas | and I think it's a good idea |
14:08:13 | t0mas | then you load just 1 bmp file... and display all images with separate tags |
14:08:32 | solex_ | and you have to specify a rectangle to display? |
14:09:01 | t0mas | yes |
14:10:08 | solex_ | Lear: no, the "VRB" is for Vorbis, bot for VBR |
14:10:44 | solex_ | VBR is not displayed - not enough space |
14:10:58 | solex_ | s/bot/not |
14:11:34 | | Quit edx (Read error: 110 (Connection timed out)) |
14:11:57 | Lear | I see. :) |
14:13:47 | solex_ | if you have a better 3-letter abbreviation... |
14:14:08 | solex_ | I didn't want to say "OGG", cause it'sjust the container |
14:14:26 | crwl | i guess "Ogg" is a lot more informative, though not really correct... |
14:15:26 | Slasheri | amiconn: oh, i will fix that |
14:15:27 | HCl | heh... |
14:15:39 | Slasheri | amiconn: can i completely remove the deprecated strings? |
14:15:44 | amiconn | No |
14:15:57 | amiconn | http://www.rockbox.org/twiki/bin/view/Main/HowtoUpdateLangfile |
14:18:11 | amiconn | Interesting effect of moving the credits to a plugin: The Ondio is the only target where you don't notice it at all |
14:18:15 | Slasheri | hmm.. i think i will hack the uplang script to do that |
14:18:32 | amiconn | Info->Version is instantaneous, as before.. :) |
14:21:58 | solex_ | I updated the vorbis.bmp |
14:22:12 | solex_ | it now shows 'OGG' |
14:22:54 | solex_ | and the zipfile now includes the .wps |
14:23:12 | solex_ | btw, does anybody know why the wps gallery page is so wide? |
14:23:52 | solex_ | ah, i found a very long line in a <verbatim> environment |
14:26:12 | solex_ | i suggest the verbatim-thing should have the css-attribute "overflow: auto;" |
14:26:30 | solex_ | that way you would get scrollbars just for the verbatim part |
14:26:42 | Zagor | solex_: good idea. i'll try that. |
14:27:01 | solex_ | thanks |
14:27:38 | | Join muesli- [0] (i=muesli_t@hmln-d514761c.pool.mediaWays.net) |
14:27:41 | solex_ | great! |
14:27:45 | Zagor | niice! |
14:27:58 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
14:27:58 | * | Zagor learned something new today |
14:28:28 | solex_ | it's a little bit annoying that (at least firefox) sends the scroll wheel event to the <pre> part |
14:28:42 | solex_ | but it's definitely better that way |
14:28:47 | Zagor | yup |
14:29:10 | | Join edx [0] (n=A@p54A86BBE.dip.t-dialin.net) |
14:30:07 | solex_ | and maybe it would look a little better if the verbatim part had a different backgound-color |
14:30:26 | solex_ | but i don't know where exactly it is used |
14:30:35 | solex_ | i mean, on which pages |
14:30:40 | solex_ | and whether it is appropriate |
14:30:53 | Zagor | it doesn't have its' own class yet, so I simply changed the <pre> tag. so I don't want to change it too much... :-) |
14:31:08 | solex_ | it's ok |
14:31:54 | solex_ | the cool thing is, that you don't have to see it all just to select, copy and paste it |
14:32:06 | Zagor | right |
14:32:15 | muesli- | hi |
14:32:53 | solex_ | moin |
14:34:07 | muesli- | moin jochen ;) |
14:34:52 | amiconn | Zagor: This overflow:auto is looking a bit strange, at least in firefox |
14:35:29 | amiconn | It still shows the vertical scrollbar even if there is nothing to scroll |
14:36:11 | solex_ | amiconn: not with my firefox (1.0.6 on Linux) |
14:36:12 | amiconn | Hmm, at least it does that for *some* of these areas |
14:36:23 | Zagor | that's odd |
14:36:31 | solex_ | oh no, you're right |
14:36:36 | amiconn | It definitely does that here with http://www.rockbox.org/twiki/bin/view/Main/WpsGallery#JoerchB |
14:36:45 | amiconn | and http://www.rockbox.org/twiki/bin/view/Main/WpsGallery#CarP |
14:37:07 | solex_ | it is because they have spaces at the end of the lines |
14:37:07 | amiconn | These don't need any scrolling here |
14:37:19 | amiconn | Firefox 1.0.6 on WinXP |
14:37:24 | amiconn | 1400x1050 screen |
14:37:24 | solex_ | try selecting the text |
14:37:27 | Zagor | doesn't do that for me |
14:37:45 | solex_ | i'll try to edit them |
14:38:01 | Zagor | oh, found one. NicolasGif has one for me. very odd indeed. |
14:38:07 | | Quit Lear (Excess Flood) |
14:39:13 | solex_ | TorstenT should be better now |
14:39:28 | | Join preglow [0] (n=thomjoha@hekta.edt.aft.hist.no) |
14:39:30 | solex_ | it's the spaces at the end |
14:39:40 | solex_ | probably happened while copy pasting from a terminal |
14:39:55 | amiconn | All gone now... |
14:40:07 | solex_ | all of them!? |
14:40:10 | amiconn | yup |
14:40:44 | Zagor | I can still trigger NicolasGif if I resize the window out and in |
14:40:50 | | Join Lear [0] (n=chatzill@h179n2c1o285.bredband.skanova.com) |
14:40:52 | Zagor | looks like a Firefox bug |
14:42:04 | solex_ | agree. misread vertical/horizontal |
14:43:07 | amiconn | Now I could trigger it by resizing for JoerchB and CarP again |
14:43:19 | amiconn | Reloading the page fixes it |
14:43:34 | amiconn | The strangeness of css... |
14:44:00 | preglow | the strangeness of css implementations |
14:45:58 | Lear | Btw, regarding the playback menu, shouldn't at least optical out and maybe anti-skip buffer be moved to the system menu? |
14:46:43 | Lear | And tag priority? |
14:49:58 | solex_ | imo optical and anti-skip should be moved to system |
14:50:09 | solex_ | and tag priority to display |
14:50:21 | | Quit hicks (Read error: 110 (Connection timed out)) |
14:51:01 | Lear | no, not display, I'd say... |
14:53:15 | Lear | Another thing I thought about recently... To support chained ogg streams (and cue sheets, I guess), the track metadata should be stored in the playback buffer, alongside the file data (like a new codec is). |
14:54:27 | Lear | That way, a more or less arbitrary number of streams (with corresponding tag info) can be stored, and support for custom vorbis and ape tags can be added without making the current metadata array too large... |
14:54:52 | muesli- | moving "playback to the uppest level and "sleep timer" to playback is my wish :o |
14:55:28 | Lear | Could be a bit tricky to handle the situation where a chained stream is (much) larger than the buffer though... |
14:56:22 | muesli- | , |
14:58:11 | preglow | lear: yes, and where the current track is too large to fit in the buffer, there'd be no next track info, then |
14:59:47 | Lear | well, it wouldn't be impossible to reserve a little space for that, I guess, but it might be tricky to do... |
15:00 |
15:00:28 | amiconn | preglow: The next track info problem also happens right now if a track is too large to fit the buffer |
15:01:09 | Lear | doesn't the iriver playback code always load the next track info, even if nothing of that track is buffered? |
15:01:51 | amiconn | I don't know. The archos playback code doesn't do that |
15:02:06 | amiconn | Imho it doesn't make sense to do that |
15:02:31 | amiconn | It costs additional battery power. I consider the next track info a little extra. |
15:03:13 | preglow | i consider it quite useless, hehe |
15:03:20 | amiconn | If it is easily made available since we are already holding (a part of) the next track in the buffer, we display it, otherwise we don't bother |
15:04:22 | amiconn | KISS, you know... |
15:05:54 | preglow | i wish someone would start adapting the codec api for non-streaming formats soon :) |
15:06:48 | amiconn | preglow: Any news on optimised codecs, profiting from the extra iram, and possibly less emac inits? |
15:07:37 | Lear | what do you mean by non-streaming? |
15:07:48 | preglow | amiconn: none other than that i'm working on it, i've got a million other things that require my attention atm, i'm hoping to get some work done today |
15:07:55 | preglow | Lear: like mods, midi |
15:08:06 | preglow | Lear: codecs that require the entire file to be loaded into the buffer at once |
15:08:22 | | Quit matsl (Read error: 110 (Connection timed out)) |
15:09:05 | Slasheri | preglow: Hmm, that should be simple to make. We would just need to guarantee that the entire file remains in the buffer all the time |
15:09:10 | preglow | Lear: apart from the buffer handling, these codecs will also very probably need to load their own data |
15:09:16 | preglow | Slasheri: read last line |
15:09:26 | Slasheri | hm |
15:09:38 | preglow | Slasheri: the loading part will mean we need another function in the codec plugins, and i don't know how to handle that |
15:10:29 | preglow | Slasheri: take for example a .mod file, you can't just read it verbatim into the buffer and expect the playback engine to have an easy time, it might have to decompress pattern data, decompress samples, etc |
15:10:35 | Slasheri | what about if we just add a configuration option like CODEC_STREAMING (true/false)? |
15:10:39 | amiconn | Imho it would be easier to support non-streaming formats via plugins first. |
15:11:03 | Slasheri | then the codec could tell the core if it requires access to the entire file constantly |
15:11:15 | | Join [1]Moos [0] (i=Moos@m29.net81-66-158.noos.fr) |
15:11:16 | preglow | Slasheri: what's more, the loading function should be able to be invoked prior to load the actual playback plugin |
15:11:19 | Slasheri | ah.. |
15:11:21 | amiconn | While that doesn't allow them to be part of a playlist (yet), it would certainly help to see what functions/ accesses are really needed |
15:11:30 | | Quit Moos (Read error: 104 (Connection reset by peer)) |
15:11:30 | | Nick [1]Moos is now known as Moos (i=Moos@m29.net81-66-158.noos.fr) |
15:11:32 | amiconn | ...and it would also help optimising them |
15:11:34 | preglow | amiconn: certainly, i expect this to be what will happen |
15:12:03 | preglow | but the things i've mentioned thus far, i'm very certain will be needed |
15:12:09 | | Quit edx () |
15:12:54 | amiconn | I think that a non-streaming codec requires flushing the audio buffer at start, and the buffer would be controlled by the codec while it is playing |
15:13:10 | preglow | why require flushing? |
15:13:27 | preglow | i don't think that will be required in the majority of cases |
15:13:30 | amiconn | For at least 2 reasons |
15:14:06 | amiconn | (1) The codec will probably need the data in contiguous form. Ordinary buffering may wrap the data around at the end of the buffer |
15:14:35 | preglow | well, sure, it can't do that if it detects a non-streaming codec |
15:14:46 | preglow | if the file is too large, it wont be loaded until the buffer is empty |
15:14:49 | amiconn | (2) The codec will possibly need extra ram. Much extra ram. |
15:14:51 | amiconn | (a) The data might be compressed |
15:15:19 | amiconn | (b) The codec might need to load largeish extra files for playback, like the instrument set for midi etc |
15:15:39 | preglow | yep |
15:15:40 | Slasheri | yes, we could give non-streamings codecs a direct access to the file buffer |
15:15:46 | preglow | we have top |
15:15:47 | preglow | -p |
15:16:03 | preglow | but it still doesn't mean the data can't coexist with what's already there |
15:16:17 | preglow | the codec just needs a means of telling the buffering layer that what's left of space isn't enough |
15:16:22 | amiconn | Yes, and it implies a short pause at the start of such a non-streaming track |
15:16:23 | preglow | and that buffering should wait until more is available |
15:17:00 | amiconn | The problem isn't to ensure enough memory is available, but to ensure it is contiguous |
15:17:21 | preglow | yep |
15:17:54 | preglow | but that's the same problem, really, afaik, the buffer doesn't contain gaps of notable size, and the only non-contiguous portion is at the end |
15:18:14 | amiconn | No, it isn't |
15:18:31 | amiconn | With ordinary buffering, the code always buffers as many tracks as fit the buffer |
15:19:02 | amiconn | That means there will already be some more tracks buffered after e.g. a midi track (*very* likely with midi) |
15:19:11 | amiconn | These need to be flushed to make room |
15:20:12 | amiconn | Resetting the whole buffer is the simplest solution here |
15:20:23 | preglow | simplest, but incredibly wasteful |
15:20:32 | preglow | i don't want to spin the disk up every time i skip to a new mod |
15:20:36 | amiconn | Everything before the non-streaming track is already decoded, and everything after it must be flushed anyway |
15:20:37 | preglow | or spc, for example |
15:20:42 | preglow | these files are 64k big |
15:21:35 | amiconn | Otherwise we would need a means for the codecs to tell the buffering system to leave extra room *at buffering time* |
15:21:49 | preglow | not if we allow the codecs themselves to load their own data |
15:21:53 | amiconn | ...probably doing a part of the decoding at load time |
15:22:03 | preglow | they'll know exactly how much they need |
15:22:17 | preglow | a mod loader will decompress pattern data and samples, and place them where they can be used when playing backj |
15:22:34 | preglow | no further space will be required |
15:22:56 | amiconn | That's what I'm trying to say all the time |
15:23:14 | amiconn | A non-streaming codec will need to do some operations *at buffering time* |
15:23:18 | preglow | oh, yes |
15:23:24 | preglow | that's what i've been saying all the time as well :P |
15:23:27 | preglow | ok, we agree then |
15:23:27 | | Join edx [0] (n=A@p54A86BBE.dip.t-dialin.net) |
15:24:01 | amiconn | ...because at start-playback time it is too late. Subsequent memory is already taken by the next track(s) |
15:24:25 | | Quit muesli- (Read error: 104 (Connection reset by peer)) |
15:24:29 | amiconn | The mod codec needs to decompress on-the-fly in case of compressed mods |
15:24:47 | amiconn | The midi codec needs to buffer the instrument set |
15:25:01 | preglow | yep |
15:25:06 | Slasheri | perhaps the metadata system could handle that. If it detecs for example a mod file being loaded, it could calculate the amount of free space we would need on the buffer |
15:25:19 | preglow | this is how most libs work anyway, they have a load function that takes a mod and prepares some internal representation of it |
15:25:31 | preglow | Slasheri: you probably can't do that without actually loading it |
15:25:45 | Slasheri | preglow: hmm, that's true too.. |
15:25:49 | Lear | but you might need pretty much all of the codec then, so metadata loading should perhaps be done by the codec... |
15:25:56 | Lear | and we have codec swapping now... :) |
15:25:59 | preglow | Lear: it should, if you ask me |
15:26:14 | Slasheri | hehe :D |
15:26:45 | Lear | need a new way to yield though, so that the currently playing codec gets a chance to do that... |
15:26:56 | amiconn | That's not possible |
15:27:16 | amiconn | The playing codec might be entirely different from the one that tries to prepare its data |
15:27:28 | preglow | we would need to split the codecs in two parts, yes |
15:27:37 | preglow | and preload all of the loader/metadata parts... |
15:27:42 | amiconn | Hehe, just wanted to say the same :) |
15:28:32 | amiconn | I didn't try how well gcc handles it, but the loader/metadata part could be built as pic |
15:28:41 | preglow | i think gcc handles it quite well |
15:28:50 | preglow | depends, of course |
15:28:57 | preglow | if you want pic with or without fixups |
15:29:07 | amiconn | This way the whole metadata handling could be made fully dynamic |
15:29:33 | amiconn | Ideally, addition of a codec doesn't require a change in th ecore |
15:29:37 | amiconn | *the core |
15:29:43 | * | preglow laments the fact that the best spc playback engine is written in x86 asm :/ |
15:29:59 | preglow | amiconn: that's what my vision of a good system would be as well |
15:30:00 | amiconn | Use an x86 emulator |
15:30:02 | amiconn | ;) |
15:30:17 | preglow | but we'd need a more complex plugin format for that |
15:30:19 | amiconn | ...with dynarec ;) |
15:30:21 | preglow | which isn't _that_ hard to do |
15:30:25 | * | preglow summons hcl! |
15:30:31 | * | amiconn looks at HCl |
15:30:57 | preglow | i've gotta go help a friend for a while |
15:31:11 | amiconn | preglow: We only need a more complex format if both parts should reside in one file |
15:31:34 | amiconn | (which I would consider a good thing) |
15:32:15 | amiconn | Doesn't need to be very complex, just a little header telling the position of the 2 parts |
15:32:49 | preglow | yes, indeed, and it would need to be relocatable |
15:33:01 | preglow | if this can't be done properly without a relocation table, we'll need that too |
15:33:08 | preglow | but now i gotta go, brb |
15:33:21 | amiconn | I would try to use full pic, without any necessary relocation |
15:33:37 | amiconn | ...for the metadata part |
15:35:44 | | Quit ashridah (Remote closed the connection) |
15:35:48 | | Join Lost-ash [0] (i=ashridah@220-253-120-92.VIC.netspace.net.au) |
15:38:51 | | Nick Lost-ash is now known as ashridah (i=ashridah@220-253-120-92.VIC.netspace.net.au) |
15:40:17 | | Join hicks [0] (n=hicks@zeus.mups.co.uk) |
15:43:25 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
15:50:02 | | Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
15:50:29 | | Quit edx (Read error: 110 (Connection timed out)) |
15:52:26 | linuxstb | I'm not saying it's definitely the best approach, but another approach would be to unify the metadata code even more, and have all the demuxing/container format code core to Rockbox, and the codecs would only actually decode the audio frames. |
15:53:04 | linuxstb | I don't see any problems with having to modify the core Rockbox in order to add support for new formats - we have already almost run out of new formats to add. |
15:54:29 | linuxstb | Also, if there is no metadata parsing in Rockbox itself, how do we know which codec to load? (the Ogg/M4A problem). |
15:59:33 | | Join edx [0] (n=A@p54A875AB.dip.t-dialin.net) |
16:00 |
16:03:38 | ]RowaN[ | has there been any progress on midi since i last asked.. erm, days and days ago =p |
16:03:59 | *** | Saving seen data "./dancer.seen" |
16:08:03 | | Join kurzhaarrocker [0] (n=none@dsl-084-061-036-048.arcor-ip.net) |
16:09:51 | | Join DMJC [0] (n=DMJC-L@220-244-239-235-sa-pppoe.tpgi.com.au) |
16:11:53 | | Join edx__ [0] (n=A@p54A86B67.dip.t-dialin.net) |
16:15:27 | | Quit ashridah ("Leaving") |
16:28:18 | | Quit edx (Read error: 110 (Connection timed out)) |
16:28:55 | | Nick edx__ is now known as edx (n=A@p54A86B67.dip.t-dialin.net) |
16:46:35 | | Quit Febs (" Want to be different? HydraIRC -> http://www.hydrairc.com <-") |
16:46:45 | amiconn | linuxstb: The core could "ask" each codec's metadata parser whether it recognises the format |
16:47:15 | amiconn | This approach is in fact old; e.g. good old DeliTracker on Amiga uses it |
16:49:26 | amiconn | If all metadata parsing is done in the core, adding a new format aways requires extending the core |
16:50:08 | kurzhaarrocker | yay! I finally managed to make the on button quit the recording screen and play the new recording. |
16:50:18 | amiconn | Then the whole modular codec architecture doesn't make much sense anymore |
16:51:40 | Lear | Doesn't make much sense to load "all" codecs (or at least the metadata part) for each file either... |
16:51:47 | preglow | well |
16:51:50 | preglow | that's what we're doing now |
16:51:54 | preglow | you don't load it for each file |
16:51:59 | preglow | you load all of them at the start |
16:52:03 | preglow | and never unload them |
16:52:29 | Lear | so they're for all practical purposes part of the core... :) |
16:52:50 | preglow | well, no |
16:52:52 | preglow | you can remove them as you please |
16:52:54 | amiconn | The metadata part needs to be present at all times |
16:52:56 | preglow | and add new ones as you please |
16:53:16 | amiconn | ..so all metadata parser parts of all codecs need to be loaded at startup |
16:53:17 | preglow | after they're loaded, then yes, it's almost the same, but i still think it's a nice distinction |
16:53:29 | amiconn | This is still different from having them built into the core |
16:54:25 | amiconn | For instance, if someone e.g. only uses mp3 and ogg vorbis, he could remove flac, wavpack etc codecs |
16:54:50 | amiconn | ...and afterwards this installation wouldn't even show flac, wavpack etc files as supported |
16:55:27 | preglow | yep |
16:55:36 | preglow | altogether preferable |
16:56:06 | preglow | but still, i wonder if the metadata parts might have to be totally distinct from the codecs, after all, several codecs share the same metadata format |
17:00 |
17:06:18 | linuxstb | IMO, there is too much similarity between all the metadata parsers to make a modular approach sensible. |
17:07:15 | amiconn | There is *currently* much similarity, but this will most likely change with non-streaming formats |
17:08:11 | amiconn | It may also change if we want to support container formats |
17:08:18 | linuxstb | The streaming formats will *always* share much similarity - even if we add non-streaming formats. |
17:08:43 | linuxstb | That's my argument in favour of keeping the metadata code unified - the metadata code handles the container format, and the codecs handle the actual decoding. |
17:09:34 | amiconn | Then we could simply link all codecs to the core as well. |
17:09:56 | amiconn | Keeping them modular is pointless without modular metadata parsing, imho |
17:10:48 | linuxstb | The reason to keep the codecs modular is that they have relatively high memory requirements, and we don't need them all at the same time. |
17:11:11 | linuxstb | But we do need all the metadata code available at the same time - to probe for file formats and decide which codec to load. |
17:11:57 | preglow | anyway |
17:12:10 | preglow | this we'll find out after a while anyway |
17:13:13 | preglow | personally i'd really like if everything codec specific was placed in plugins |
17:14:29 | kurzhaarrocker | I want to break a gui design rule |
17:15:30 | kurzhaarrocker | When the user returns from adjusting a setting he normally expects to return to the menu where he entered chose the parameter from |
17:15:59 | linuxstb | preglow: It depends how you define "codec specific". Are ID3 tags codec specific? Or parsing of an Ogg container? |
17:16:49 | kurzhaarrocker | But not when he is in the recording screen. Quitting the recording screen shouldn't return to the menu but to the browser. |
17:17:15 | kurzhaarrocker | Or maybe to the wps screen, when he has resume enabled. |
17:17:30 | amiconn | kurzhaarrocker: I disagree here |
17:18:01 | amiconn | The recording screen is entered from the menu. Everything else than exiting back to the menu would be really confusing |
17:18:04 | kurzhaarrocker | It is pain in the a** to have to press n buttons to finally find the new recording. |
17:18:18 | preglow | linuxstb: i meant more like anything relating to codecs, if a user doesn't ever use ogg files, it would be neat if he could just not include the ogg parser |
17:19:40 | kurzhaarrocker | returning to the menu seems more logical, that's true, but it is not ergonomical. |
17:20:00 | amiconn | Unlogic behaviour isn't ergonomical either |
17:21:01 | amiconn | The recording screen could provide a method to start playback of the latest recording, but leaving the ordinary way should always bring you back where you came from |
17:21:08 | kurzhaarrocker | I think that it isn't _that_ confusing because a recording takes a while. When I press stop after a recording I hardly know where in the menu I really was. |
17:21:42 | amiconn | Recording doesn't always take long, e.g. when recording voice notes |
17:21:52 | kurzhaarrocker | That's the way I have implemented it right now, but it feels very complicated. |
17:21:57 | amiconn | Btw, that reminds me of that missing trigger mode... |
17:22:03 | kurzhaarrocker | :) |
17:22:37 | preglow | btw, am i the only one thinking the buffering algo should be configurable? i generally want rockbox to load the entire buffer fully when i press afile, not just a tiny bit, before resuming later |
17:22:42 | amiconn | You could call the wps from the recording screen. Stopping would bring you back to the recording screen then |
17:23:43 | kurzhaarrocker | Directly calling the wps is problematic as it could result in stack problems when you go wps -> menu -> recording -> wps -> menu -> recording ... |
17:24:11 | amiconn | Of course such circles need to be prevented |
17:24:58 | amiconn | Perhaps each screen should have a status variable, stating whether this screen is already in use |
17:25:14 | kurzhaarrocker | Thus I made the on button _return_ straight down to the browser from the recording screen. (works even if you were in wps meanwhile) |
17:25:20 | amiconn | Calling it a second time would immediately return with an error messange (splash) |
17:26:04 | kurzhaarrocker | I abused the usb mode for that. |
17:26:11 | amiconn | This way you could e.g. do wps->menu->recording->wps?MEEEP! |
17:26:43 | | Quit hicks (Read error: 110 (Connection timed out)) |
17:26:43 | amiconn | Or browser->menu->recording->wps->menu->recording?MEEP! |
17:26:57 | amiconn | Note: menu isn't a screen in this sense |
17:27:54 | kurzhaarrocker | No when the menu->recording was chosen from wps it returns to wps - which immediately returns to the browser because of usb mode. |
17:28:04 | Lear | amiconn: the context menu breaks that rule. Go to sound menu (from wps), then when you exit that, you drop back to the wps, and not the context menu. |
17:28:56 | amiconn | Yes. The context menu is a bit different, in that selecting something in a submenu drops you back out. |
17:29:09 | preglow | must one reboot for voice ui to take effect? |
17:29:29 | amiconn | Even that is slightly confusing, but acceptable |
17:29:50 | preglow | man, voice ui clips like mad on iriver |
17:30:12 | | Quit tvelocity (Read error: 113 (No route to host)) |
17:30:43 | Wy | Hrm. Hey, I'm kinda stupid, but anyone know where the firmware for the jukebox recorder is? |
17:30:52 | Wy | Link on the site is broken |
17:30:55 | | Join muesli- [0] (i=muesli_t@Bbca4.b.pppool.de) |
17:31:15 | kurzhaarrocker | Let's delete the link - who cares about archos firmwares :) |
17:31:31 | Wy | (= |
17:31:38 | linuxstb | preglow: I'm not sure what a user would gain by (e.g.) removing Ogg support. |
17:32:18 | Wy | Heh, I finally found the time to dump my 80gb drive into my recorder |
17:32:34 | Wy | Btw, anyone also know of a good way to, say ... synch the recorder to itunes? |
17:33:32 | preglow | linuxstb: more space for other things than functions that will never be used? |
17:33:44 | preglow | linuxstb: less time used in format checking? |
17:34:50 | Slasheri | if we don't have any metadata parsing inside the core, then we would need to scan and load all plugins to retrieve some info from them. And that will add very much complexity to the code |
17:34:59 | linuxstb | Both are insignificant IMO. Are we short of space on the iriver? |
17:35:20 | preglow | Slasheri: i think 'very much' is exagerating |
17:35:33 | Slasheri | i think it's not.. |
17:35:51 | Slasheri | we have to deal with all performance problems etc. also |
17:36:05 | preglow | it's not any worse than just including a few fixed size fields at the start of a plugin |
17:36:27 | preglow | or a struct |
17:36:37 | preglow | good old linker magic |
17:36:41 | kurzhaarrocker | We cannot play a song without it being in a playlist, can we? |
17:37:05 | preglow | but anyway, this isn't very important right now, i suggest we take this up again once we have more of the code we're discussing |
17:37:07 | Slasheri | we would need to run two plugins at the same time while parsing metadata and playing. If we also want to use voice ui, that will be complex enough |
17:37:39 | preglow | Slasheri: we were talking about making the parser code position independent and loading all of them at startup |
17:37:59 | Slasheri | Hmm.. |
17:38:06 | preglow | Slasheri: the parsing would be pretty much seperate from the main codec action |
17:38:15 | Slasheri | ah, that sounds better |
17:39:12 | preglow | still, like i said, there are more important things to be done now, whether this is done one way or the other, it doesn't much touch how the user perceives rockbox |
17:39:21 | preglow | it's a code thing |
17:39:48 | | Join paugh [0] (n=pete@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
17:40:02 | linuxstb | So what is more important at the moment? (I'm asking seriously - I'm looking for jobs). |
17:40:14 | amiconn | Slasheri: We don't need to run 2 plugins at once. This would indeed add complexity |
17:40:21 | Slasheri | linuxstb: Hmm, remote support? :) |
17:40:29 | linuxstb | I've lost my remote... :( |
17:40:49 | Slasheri | amiconn: true if we handle the metadata parsing outside from codecs (as it's now) |
17:40:55 | amiconn | If we split the codec plugins in 2 (still within one file), the metadata parsers of all codecs would be loaded into the "metadata parser code buffer" at startup |
17:41:32 | amiconn | Then the core would just ask each parser if he recognises a certain format (simple loop across all parsers) |
17:41:59 | preglow | the only thing we'd need to keep in the core is a set of codec identifiers to be passed around |
17:42:23 | amiconn | Each codec can be assigned a unique identifier at build time |
17:42:30 | preglow | a string would be nice, actually |
17:42:54 | preglow | so the different parts at least stand a chance to work across different compiles of rockbox |
17:42:55 | amiconn | I think a 4-char identifier would be sufficient |
17:42:58 | preglow | yup, agreed |
17:43:11 | amiconn | It can be passed in a long, and still recognisable as a name |
17:43:25 | preglow | hmm, what asm restraint can i use for 4 byte constant? |
17:43:30 | preglow | constraint, that is |
17:43:40 | amiconn | ? |
17:43:56 | amiconn | What do you mean? |
17:44:21 | preglow | i'm adding a flags parameter to mc5249_init_mac |
17:44:45 | amiconn | Where do I find that? |
17:44:47 | preglow | which is inline, so i want the asm statement to put a constant where %0 is |
17:44:51 | preglow | export/system.h |
17:44:51 | * | amiconn is trying to multitask... |
17:45:25 | Lear | preglow: voice ui probably clips becase the samples are multiplied by 4... |
17:45:28 | preglow | like, where #0x20 is now, i want %0 to be, which i want to be replaced by a constant, not a register, to make the tightest code. this might ofcourse not be possible :P |
17:45:32 | preglow | Lear: yes, i know |
17:45:49 | preglow | Lear: doesn't sound too clever ;) |
17:46:00 | amiconn | preglow: Ah, you're looking for the 32 immediate constraint. Hmm. |
17:46:32 | amiconn | Lear: Why the heck is this?? |
17:46:48 | * | amiconn tries to find out from gcc source |
17:46:51 | | Quit muesli- (Read error: 104 (Connection reset by peer)) |
17:46:55 | Lear | amiconn: ask slasheri. :) apparantly the volume was quite low otherwise... |
17:46:56 | preglow | amiconn: i think slasher said it sounded really weak without |
17:47:32 | amiconn | The voice files aren't full volume, for a reason |
17:47:32 | Slasheri | yep, that was the problem |
17:47:45 | amiconn | However, multiplying by 4 will make them clip |
17:47:50 | Slasheri | with some songs it was hard to hear the voice ui while playing |
17:48:11 | amiconn | All voice files generated by me are scaled to 60% level (linear) |
17:48:16 | preglow | Slasheri: i think the music should be enveloped a bit while playing |
17:48:21 | Slasheri | maybe even multiplying with 2 would be enough |
17:48:21 | preglow | Slasheri: playing voice clips, that is |
17:48:44 | preglow | at least, that'd be a nice option |
17:48:57 | Slasheri | hmm, decreasing music volume while playing voice samples? that is a great idea :) |
17:49:35 | amiconn | Originally the voice files were generated at full volume, but for Bagder's sensitive ears ;-) (or was it Zagor?) the voice was too loud compared to the music, so we lowered it |
17:50:01 | amiconn | That was on archos of course, where voice + music is impossible |
17:50:31 | preglow | Slasheri: a nice option would be how many decibels to lower music when voice is playing |
17:50:43 | | Join webguest51 [0] (n=8ddfd339@labb.contactor.se) |
17:50:46 | amiconn | I think multiplying by 2 plus lowering music volume should be enough. Better no multiplication when no music is playing |
17:50:50 | Slasheri | preglow: true, that should be implemented :) |
17:51:16 | preglow | think i'll try the i constraint |
17:51:59 | kurzhaarrocker | loud voices are good for commercials. "IM JAMBA MONATSPAKET!!" :) |
17:52:15 | amiconn | urgs |
17:54:58 | preglow | no constraint match, hrmf |
17:55:19 | preglow | perhaps i should just make it a macro instead of an inline function |
17:55:22 | preglow | that ought to make it easier |
17:57:00 | preglow | yup, that worked, i assume you guys don't frown on macros? ;) |
17:58:17 | preglow | Slasheri: there bug with a track change skipping back and forth between the previous track and the new track is still here, any idea why? |
17:58:23 | amiconn | Inline function is preferred |
17:58:39 | amiconn | Try K or M constraint |
17:58:59 | amiconn | http://savannah.gnu.org/cgi-bin/viewcvs/gcc/gcc/gcc/config/m68k/m68k.md?rev=1.49.2.14.2.3.2.2&content-type=text/vnd.viewcvs-markup |
17:59:11 | amiconn | Look for "Immediate integer operand constraints" |
17:59:14 | preglow | amiconn: M wont do |
17:59:19 | preglow | amiconn: it's for 5 bit numbers |
17:59:44 | amiconn | Huh? |
17:59:55 | preglow | Integer in the range 0 to 32 |
18:00 |
18:00:25 | amiconn | The m68k machine description says different... |
18:00:38 | preglow | shit, i'm looking at the wrong arch |
18:01:25 | preglow | both K and M set requirements to how large the number is |
18:01:27 | preglow | i can't use that |
18:02:36 | preglow | esp since the flags will always be lower than 0xf0 |
18:02:45 | preglow | might even be 0 |
18:03:16 | preglow | doesn't work anyway, i think it's gccs processing of inline functions that are causing the grief |
18:03:24 | preglow | #define coldfire_init_emac(flags) \ |
18:03:24 | preglow | asm volatile ("move.l %0, %%macsr" \ |
18:03:24 | preglow | : : "i" (flags)); |
18:03:28 | preglow | that works perfectly |
18:03:43 | preglow | if the inline equivalent doesn't work, it's not the constraints fault |
18:04:01 | *** | Saving seen data "./dancer.seen" |
18:04:40 | amiconn | You used a lowercase i ?? |
18:05:27 | preglow | indeed |
18:05:42 | preglow | the uppercase wont sure as hell wont work for m68k |
18:05:46 | preglow | that's a number from 1 to 8 |
18:07:03 | preglow | hmm, seems like it works if i make the argument const |
18:07:30 | amiconn | Ah yes, and yes |
18:08:29 | Slasheri | preglow: Hmm, i will try that soon (no ideas yet) |
18:10:25 | preglow | Slasheri: i switch a track, i hear about a second of new audio, then the old one glitches in again, then i get the new one, and it stays |
18:11:35 | | Join amiconn_ [0] (n=jens@p54BD6FF5.dip.t-dialin.net) |
18:11:49 | | Quit amiconn (Nick collision from services.) |
18:11:50 | | Nick amiconn_ is now known as amiconn (n=jens@p54BD6FF5.dip.t-dialin.net) |
18:12:35 | | Nick paugh is now known as AliasCoffee (n=pete@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
18:13:17 | Slasheri | preglow: ah, that might be a performance problem. I think you have crossfade disabled |
18:14:14 | preglow | Slasheri: no, i haven't |
18:14:25 | preglow | Slasheri: i've never had it enabled, and i've pretty much always had this bug |
18:15:03 | preglow | Slasheri: ehh, disabled, yes, i have it disabled :P |
18:15:11 | preglow | i should actually read what people say to me |
18:15:27 | Slasheri | :D |
18:15:28 | preglow | but how can _disabled_ crossfade give a performance problem? |
18:16:26 | CoCoLUS | <fn~preglow> Slasheri: i switch a track, i hear about a second of new audio, then the old one glitches in again, then i get the new one, and it stays |
18:16:30 | CoCoLUS | i get that, sometimes, too |
18:16:43 | Slasheri | that is a problem with audiobuffer flushing (it tries to provide continuous playback always when possible). If there is no new data coming fast enough, part of previous data could be heard |
18:16:49 | CoCoLUS | crossfade not enabled |
18:16:59 | Slasheri | i think we could tune that flushing a bit to get rid of the problem |
18:18:24 | preglow | that would rock |
18:18:34 | CoCoLUS | what bothers me the most about the current playback system is that it's impossible to skip a few tracks instantly |
18:19:41 | CoCoLUS | repeatedly pressing next/previous track, that is |
18:20:20 | CoCoLUS | it works perfect for the next one or two tracks, but after that, it loads a few seconds for every track, and it won't accept any new button presses |
18:20:31 | preglow | amiconn: there, i've removed all but one emac init in each codec, seems to work just fine and dandy |
18:26:31 | amiconn | Nice :) |
18:26:39 | amiconn | Now for the iram usage part... ;) |
18:34:42 | | Join tvelocity [0] (n=tony@ipa175.1.tellas.gr) |
18:40:49 | kurzhaarrocker | funny. It seems to be a bad idea do declare a variable in the *.h file as "extern char* filename;" and then define it in the *.c file as "char filename[MAX_PATH];" |
18:41:04 | kurzhaarrocker | I always thought that both were the same. |
18:41:46 | amiconn | They aren't |
18:42:21 | amiconn | The former is a pointer, the latter is an array |
18:44:03 | kurzhaarrocker | I thought that char arrays internally were the same as a pointer to a char. I thought wrong |
18:44:39 | amiconn | There are several differences |
18:45:14 | preglow | amiconn: i already did some layer12 work, but i've got a hard time measuring the improvements, need to code a quick realtime usage indicator first |
18:45:54 | amiconn | A pointer to a char always takes 4 bytes, which store the address of a string. No space is reserved for the string by the pointer declaration itself |
18:46:02 | | Quit edx () |
18:46:46 | amiconn | A char array takes as many bytes as you give it within the []. The address itself isn't stored, it is implicit |
18:47:22 | amiconn | (known symbol at compile time, resolved at link time, fixed at runtime) |
18:48:03 | kurzhaarrocker | So it is the compiler that automatically converts when you assign a char array to a char pointer? |
18:48:18 | amiconn | So char hello[] = "Hello" takes 6 bytes, while char *hello = "Hello" takes 10 |
18:48:48 | amiconn | It doesn't convert, it just writes the (fixed) array address into the pointer variable |
18:50:21 | kurzhaarrocker | So char *hello = "Hello" does both: generate an anonymous array and a named char pointer. |
18:50:34 | amiconn | In my 2 examples, the former declares the array 'hello' whose address is fixed, while the latter declares the pointer 'hello' which initially points to the string "Hello" |
18:51:22 | | Quit webguest51 ("CGI:IRC") |
18:54:09 | amiconn | Bleh, "panic: rec upd: -7" :-( |
18:54:27 | amiconn | Obviously there's something wrong with my new xing header creation code... |
18:55:45 | preglow | hrmph |
18:55:53 | preglow | i'm including system.h in codec.h |
18:56:52 | preglow | amiconn: is the voice ui any closer to archos behaviour with the new iram stack, btw? |
18:56:54 | amiconn | Mrf, this stand under not do I |
18:59:22 | * | amiconn is silly |
18:59:53 | amiconn | Of course this can't work... I try updating the new file (after the split) which does not yet exists at that point.... |
19:00 |
19:00:43 | * | preglow gets scared by the static |
19:01:37 | amiconn | open() return value -7 means ENOENT... |
19:02:11 | * | preglow loves bugs that appear ,then disappear |
19:02:44 | | Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU) |
19:02:46 | amiconn | Blinkenbugs... I know this evil type :/ |
19:03:29 | preglow | hmm |
19:03:33 | preglow | something's wrong here |
19:04:12 | | Quit tvelocity (Read error: 113 (No route to host)) |
19:09:03 | kurzhaarrocker | ENO ENT? Is that a brother of Treebeard? |
19:09:22 | amiconn | Haha, no. ENOENT means Error NO ENTry |
19:09:27 | amiconn | (in the directory) |
19:09:29 | kurzhaarrocker | :) |
19:11:23 | | Quit cYmen ("wusch") |
19:14:07 | | Join [1]Moos [0] (i=Moos@m29.net81-66-158.noos.fr) |
19:14:08 | | Quit Moos (Read error: 104 (Connection reset by peer)) |
19:14:11 | | Nick [1]Moos is now known as Moos (i=Moos@m29.net81-66-158.noos.fr) |
19:15:38 | | Join nc [0] (i=nc@dyn162.her1.nas.panafonet.gr) |
19:16:11 | nc | hi all. |
19:16:52 | nc | is the 2.5 rockbox to be released tomorrow? does anyone know? |
19:18:29 | | Join wubbla [0] (n=wubbla@adsl-212.199.166.194.arpa.as1901.net) |
19:18:34 | wubbla | ahoi! :D |
19:18:53 | kurzhaarrocker | Personally I'd like linus (or someone else) to apply a patch that fixes a ui problem first: http://sourceforge.net/tracker/index.php?func=detail&atid=439120&group_id=44306&aid=1179046 |
19:21:46 | nc | i thought they did not tale any more requests since the 2.5 freeze. |
19:22:21 | kurzhaarrocker | Linus agreed that this specific patch is more a bug fix than a new feature. |
19:22:25 | preglow | Slasheri: do both codecs run in seperate threads? |
19:22:32 | | Join OnkelJonas [0] (i=kartoffe@ip230.rev112.brygge.net) |
19:22:34 | wubbla | are there any new successes concerning the h300 port? |
19:22:58 | nc | anyone here tried any previos versions of rockbox? I am new here and own a iHP-140 and wonder whether i should give 2.5 a go. |
19:23:10 | OnkelJonas | sure |
19:23:13 | preglow | nc: that wont work on iriver |
19:23:25 | nc | 2.5? |
19:23:34 | OnkelJonas | just get a "daily build" |
19:23:38 | kurzhaarrocker | rockbox v2.5 won't be an official releas for iriver |
19:23:42 | amiconn | preglow: Yes (your qn to Slasheri) |
19:24:01 | preglow | amiconn: i'm getting audio corruptions sometimes now |
19:24:06 | preglow | but only with voice ui |
19:24:11 | nc | oh, just for Achos? and then they might make it for iRiver as well? |
19:24:14 | amiconn | Hmm. |
19:24:25 | OnkelJonas | nc: http://www.rockbox.org/auto/build-h120/rockbox.zip <−−- that will work on the iriver (h140 too) |
19:24:52 | nc | thx |
19:25:26 | preglow | amiconn: ignore me, it's probably my fault |
19:25:27 | OnkelJonas | you need to install the firmware first though - looking for the link |
19:25:42 | kurzhaarrocker | nc: rockbox for iriver still is considered 'alpha' |
19:26:02 | | Quit matsl (Read error: 110 (Connection timed out)) |
19:26:02 | OnkelJonas | http://www.rockbox.org/twiki/bin/view/Main/IriverBoot |
19:26:09 | nc | you mean version 2.4 is alpha? |
19:26:52 | OnkelJonas | the iriver port is alpha |
19:26:54 | kurzhaarrocker | 2.4 is a release for the _archos_ players. The port to the iriver players is still in progress. |
19:27:45 | OnkelJonas | but very stable, and no dead players yet afaik |
19:28:07 | amiconn | Nah, not *very* stable, at least not for me |
19:28:29 | amiconn | It's somewhat stable, but I know numerous ways to make it freeze, reproducably |
19:28:45 | nc | did it cause any trouble to your player amiconn? |
19:28:51 | amiconn | no |
19:29:03 | amiconn | You can always reset |
19:29:15 | nc | so u recommend trying it out? |
19:29:21 | OnkelJonas | yes |
19:29:38 | amiconn | In fact I help developing it :) |
19:29:49 | nc | ok. and i can always go back to iriver's firmware, right? |
19:29:57 | OnkelJonas | you can easily boot to iriver firmware, and in my experience "normal" usage rarely crash it now |
19:30:25 | OnkelJonas | yes |
19:30:32 | dpassen1 | i haven't booted up the iriver firmware in months |
19:30:40 | | Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
19:30:48 | nc | that well,e? :) |
19:31:26 | OnkelJonas | i boot it occasionally for the 1 album i have in wma format, and for radio |
19:31:43 | nc | so tomorrow we will have the 2,5 firmware. does anyone know when the iriver port will be ready for 2.5? |
19:31:45 | OnkelJonas | but there is even radio in rockbox now, although still pretty basic |
19:33:11 | nc | If i get this right there is a global firmware and specific ports for each player? (archos,iriver)? |
19:34:18 | OnkelJonas | a lot of the code is shared across players, but since they have different hardware it is not compatible |
19:34:30 | kurzhaarrocker | all those players have completely different hardware that must be adressed differently. |
19:34:31 | OnkelJonas | so you download for a specific player |
19:35:55 | nc | ok. so there 's no need to wait for 2.5 for iriver since it would take a while for a port to be available, and i should go for 2.4. |
19:36:16 | kurzhaarrocker | There's no V2.4 for iriver |
19:36:32 | nc | errrr. i am a little confused |
19:36:47 | nc | :) |
19:36:49 | kurzhaarrocker | There's no official version for the iriver at all. |
19:36:54 | OnkelJonas | there is no "V XXX" for iriver since it is still in development |
19:36:56 | kurzhaarrocker | Development is in progress |
19:37:11 | OnkelJonas | so you should get a "daily build" |
19:37:37 | kurzhaarrocker | When rockbox V2.6 is released it may be for the iriver too. |
19:38:17 | preglow | i wonder why vorbis has suddenly started crapping its pants |
19:38:45 | nc | oh i see. so i am just an average user. do u recommend i try the daily use and keep in touch w/ he project? |
19:39:02 | nc | sorry for all the questions |
19:39:20 | nc | i am trying to understand what is going on. |
19:39:53 | OnkelJonas | sure... personally I check the page for recent development ~once a week, and get a new build |
19:40:13 | kurzhaarrocker | You can try the daily builds, but expect errors and make sure you backup important data on your iriver first. |
19:41:03 | | Quit cYmen ("leaving") |
19:41:06 | nc | the worst that can happen (from user experience ) is data loss only? and as i was told the reset button help out. |
19:41:35 | nc | if that's the worse that's happened so far i am willing to test it |
19:42:07 | OnkelJonas | every report of dead players I've seen so far turned out to be solvable by simpæly using reset |
19:42:09 | amiconn | Ahahaha, discovered an old bug in mpeg.c: a missing break at the end of a case: |
19:42:24 | Rick | Don'tcha love those? |
19:42:46 | amiconn | Introduced by me (tm) 3 months ago... |
19:43:13 | nc | thanx guys i am going now to try rockbox. :) |
19:43:18 | Rick | Heh heh heh |
19:43:21 | Rick | nc: Good luck ;) |
19:43:28 | nc | thx |
19:45:10 | OnkelJonas | so when do we tell him that rockbox will fry his player at first boot? |
19:45:22 | OnkelJonas | :P i keed i keed |
19:46:36 | kurzhaarrocker | nc: make sure you wear safety glasses and gloves when you try rockbox first. |
19:47:19 | nc | you guys |
19:47:44 | nc | does is support any gnuboy games btw? |
19:47:51 | preglow | amiconn: i don't get this, i actually need to have more than just one emac init in vorbisfile.c for it to work |
19:49:22 | OnkelJonas | it supports gameboy games is all i know, but dont expect all of them to run at full speed |
19:50:29 | nc | tetris and snake is all i need :) |
19:50:38 | nc | (for beginners) |
19:51:03 | | Join tvelocity [0] (n=tony@ipa175.1.tellas.gr) |
19:51:24 | HCl | i need to do some optimizations for gnuboy |
19:51:26 | kurzhaarrocker | pah. snake. Play wormlet! More worms! Artificial stupidity! Aarghs! |
19:51:28 | HCl | but i'm not sure how :/ |
19:51:52 | preglow | hcl: optimised cpu core, find variables to iram |
19:51:54 | amiconn | preglow: That's strange. Is there any codec code that is called outside the codec thread (or voice thread, for voice codec)? |
19:52:18 | HCl | preglow: first i'd like to add asm functions of certain optimizable functions |
19:52:22 | amiconn | kurzhaarrocker: wormlet still runs on recorder only |
19:52:22 | preglow | amiconn: seems its only needed one place, i placed it in the first function i saw vorbis.c call, but that didn't cut it, it _needs_ to be placed in ov_read_fixed |
19:52:27 | HCl | i believe amiconn already did this for archos |
19:52:42 | kurzhaarrocker | What a shame, amiconn. |
19:52:57 | kurzhaarrocker | <- can't fix that, doesn't have any irivers |
19:53:23 | amiconn | I was unable to adapt wormlet to variable button assignment. Wormlet's button handling is scattered all over the code... |
19:53:45 | amiconn | It would probably be easier to rewrite wormlet than to adapt it... |
19:53:57 | kurzhaarrocker | :) |
19:54:35 | OnkelJonas | is bmp support broken in recent builds? |
19:54:35 | OnkelJonas | i just installed the latest, and the wps's show up without bmp's |
19:54:59 | solex_ | no, works here |
19:55:01 | dpassen1 | the syntax has changed |
19:55:36 | OnkelJonas | probably that... is it in the wiki? |
19:55:40 | dpassen1 | yes |
19:55:44 | linuxstb | Anyone know if there are byte-swap macros centrally defined in rockbox - e.g. to convert a 32-bit int from big-endian to host-endian? |
19:56:13 | preglow | oh yes |
19:56:30 | preglow | in system.h, afaik |
19:56:49 | preglow | SWAB32, for example |
19:56:57 | amiconn | Yes and no |
19:57:24 | amiconn | The byte swap macros in system.h are for converting little-endian to host-endian |
19:57:38 | amiconn | There are no macros to convert from big-endian to host-endian |
19:58:20 | linuxstb | I need them for my .m4a code (alac today and maybe aac in the future). Would it make sense to add them? |
19:58:34 | amiconn | ...and the SWA??? macros work on variables only, no unaligned read etc |
19:58:53 | | Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
19:59:00 | nc | do i get the latest build for iriver here: http://www.rockbox.org/daily.shtml ? |
19:59:20 | linuxstb | My code currently reads 4 bytes from a file into an integer, and then byte-swaps it if necessary (which is only necessary on little-endian simulators) |
20:00 |
20:00:33 | | Quit OnkelJonas (Read error: 104 (Connection reset by peer)) |
20:01:20 | kurzhaarrocker | yes, nc |
20:01:42 | linuxstb | But the macros seem to be assember-optimised. Does that mean they wouldn't work in a Simulator? |
20:02:04 | | Join OnkelJonas [0] (i=kartoffe@ip230.rev112.brygge.net) |
20:02:24 | nc | thx |
20:02:40 | Lear | preglow: dsp uses emac too, probably uses a different mode. |
20:03:25 | Lear | linuxstb: a simulator version should be around. |
20:03:29 | amiconn | Lear: Yes, but dsp does run in a different thread, doesn't it? |
20:03:37 | kurzhaarrocker | Do patches only appear on the rockbox site when you do not forget to specify the category? |
20:03:50 | Lear | nope, codec calls code to insert in pcmbuf, no context switches there... |
20:03:54 | preglow | Lear: well, macsr is now saved in the thread context |
20:04:05 | preglow | Lear: and dsp runs in a different thread than the codec, no? |
20:04:06 | *** | Saving seen data "./dancer.seen" |
20:04:10 | Lear | but dsp is run in codec context... |
20:04:16 | amiconn | ouch |
20:04:18 | preglow | arghhhh |
20:04:24 | preglow | stILL |
20:04:25 | | Join [MuIL]SpongeBoB [0] (i=LordRon@80.178.0.207.adsl.012.net.il) |
20:04:32 | preglow | why would dsp need anything other than frac mode? |
20:04:45 | Lear | didn't you write the resampler? |
20:04:50 | preglow | i did |
20:04:53 | preglow | and it uses frac mode |
20:04:56 | [MuIL]SpongeBoB | hey sorry for the dummy question. I have Iriver H10 what version of Rockbox do I need? |
20:05:04 | preglow | [MuIL]SpongeBoB: not supported |
20:05:06 | Lear | well, it does use saturation mode, iirc... |
20:05:14 | preglow | Lear: as does all other codecs now |
20:05:22 | preglow | Lear: i see no reason for not using saturation |
20:05:25 | Lear | I see... |
20:05:31 | preglow | only thing varying is rounding |
20:05:43 | preglow | which tremor can't use because of MULT31_SHIFT15 |
20:05:51 | preglow | well |
20:06:01 | preglow | half the reason for the macsr context save vanished |
20:06:04 | Lear | dsp uses #b0 mode... |
20:06:18 | preglow | b0 is frac and round |
20:06:28 | preglow | no |
20:07:12 | Lear | standard mac init (in system.h) is 0x20, dsp uses 0xb0... |
20:07:15 | | Join muesli- [0] (i=muesli_t@hmln-d9b8e251.pool.mediaWays.net) |
20:07:32 | Lear | you know what works in dsp.c, I guess... :) |
20:07:43 | muesli- | re |
20:08:08 | linuxstb | [MuIL]SpongeBoB: Rockbox doesn't support the H10. Only H120/H140 at the moment, with work just starting on H300 |
20:08:21 | [MuIL]SpongeBoB | thanks.. |
20:08:43 | | Quit [MuIL]SpongeBoB (Client Quit) |
20:09:41 | linuxstb | Lear: I can't find any simulator versions of SWABNN - I think they are only used in the low-level firmware code, which isn't in the sims. |
20:11:00 | Lear | I'm pretty sure it is, at least for little endian platforms (i.e., x86)... |
20:11:07 | nc | i just installed Rockbox on my iHP-140!!! :) :) and i like the interface a lot!!!! thumbs up for developers and everyone that helps. |
20:11:36 | linuxstb | For little-endian, it's just #defined as SWAB32(x)=x |
20:12:18 | linuxstb | Has anyone ever compiled a simulator on a big-endian machine? |
20:12:36 | Lear | perhaps not... :) |
20:12:38 | preglow | arghhhh |
20:12:40 | preglow | tea everywhere |
20:13:11 | Lear | linuxstb: you on ppc? |
20:13:55 | linuxstb | Sometimes. I sometimes use an iBook running Mac OS X. |
20:14:21 | Lear | well, should be easy enough to convert the iriver swab32 code to C... |
20:15:34 | linuxstb | There is already a C definition, but #ifdef'ed for the TCC730 processor. |
20:15:42 | | Join Mark_ [0] (n=Mark@cpc1-bele3-3-1-cust167.belf.cable.ntl.com) |
20:16:12 | linuxstb | But "swab" (swap adjacent bytes) doesn't seem to be the correct name for the function - if it only works for little-endian to host-endian conversions. |
20:16:19 | kurzhaarrocker | Your iriver didn't explode, nc? |
20:20:35 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
20:20:46 | | Part OnkelJonas |
20:20:59 | | Join OnkelJonas [0] (i=kartoffe@ip230.rev112.brygge.net) |
20:22:39 | amiconn | Wee, enhanced xing header generation already works quite well. Some minor quirks still to be fixed... |
20:25:02 | preglow | why does dsp run in codec context anyway? |
20:25:27 | muesli- | amiconn dont you watch the chancellor duell? ;)= |
20:27:05 | muesli- | -l |
20:27:09 | amiconn | muesli-: Why should I? |
20:27:13 | | Join silencer_ [0] (n=silencer@zen.via.ecp.fr) |
20:27:33 | muesli- | interesting if you ask me |
20:28:08 | muesli- | wont change my dicision |
20:28:33 | muesli- | but am curious ;) |
20:29:09 | Lear | why do a context switch just to write data to pcmbuf? |
20:29:54 | Lear | so why not let dsp run in codec context (apart from the macsr thing)? |
20:33:14 | preglow | well |
20:33:19 | preglow | it would make more sense having it in the audio thread |
20:33:41 | preglow | Slasheri: got anything to say on this? |
20:35:01 | Lear | wouldn't that just complicate things, and add processing (first copy data to pcmbuf, then run dsp over it, keeping track of what is processed and what isn't)? |
20:35:11 | Slasheri | Lear: Hmm, we are making a context switch to write data to pcmbuf? |
20:35:36 | Lear | slasheri: no, were're not, and that's what preglow is "complaining" about... |
20:35:43 | Slasheri | oh, ok |
20:36:39 | Slasheri | i think the current aproach is quite performance effective |
20:42:55 | | Quit kurzhaarrocker () |
20:42:55 | | Quit AliasCoffee ("bbl") |
20:44:27 | | Quit nc (Read error: 113 (No route to host)) |
20:46:07 | | Join Mxm`Pas`Bien [0] (n=flemmard@fbx.flemmard.net) |
20:46:08 | | Quit Maxime (Read error: 104 (Connection reset by peer)) |
20:51:11 | preglow | Slasheri: hmm, yes, but it kind of defeats what we've done with the macsr context save |
20:51:30 | preglow | dsp should at least save it so the codecs don't have to worry about it being clobbered |
20:52:18 | Slasheri | yes, that's true |
20:55:03 | | Quit muesli- (Read error: 113 (No route to host)) |
21:00 |
21:00:09 | linuxstb | Does anyone understand this bug (from ReleaseTodo): "The %F WPS conditionals don't work as expected since the enum change" |
21:01:32 | | Join [1]Moos [0] (i=Moos@m29.net81-66-158.noos.fr) |
21:01:53 | | Quit Moos (Read error: 104 (Connection reset by peer)) |
21:01:53 | | Nick [1]Moos is now known as Moos (i=Moos@m29.net81-66-158.noos.fr) |
21:03:14 | | Quit ansivirus (Remote closed the connection) |
21:07:06 | linuxstb | Slasheri: In the read_next_metadata() function in playback.c, the codectype is set back to 0 (after a call to probe_file_format sets the value). Do you know why that is? |
21:10:45 | dpassen1 | linuxstb: i understand it, i believe |
21:11:30 | linuxstb | Explain :) |
21:11:44 | dpassen1 | there was a CVS change, i'm looking for it |
21:11:49 | | Join webguest28 [0] (n=d5ee4633@labb.contactor.se) |
21:11:59 | dpassen1 | and since, the next file (capital F) in the WPS does not work as it should |
21:13:24 | linuxstb | Yes - the %Fc tag no longer works for the next track info - because the codectype has been set to zero. |
21:13:59 | linuxstb | I think the playback code uses zero to indicate "codec not loaded", but the rest of rockbox uses it to mean unknown codec. |
21:16:16 | Lear | maybe wps-display should use id3->codectype + 1 for the codectype intval then... |
21:17:52 | linuxstb | I can't think of any alternatives. |
21:18:20 | | Quit Sucka (Read error: 110 (Connection timed out)) |
21:19:21 | linuxstb | The relevant change in playback.c is here: http://www.rockbox.org/viewcvs.cgi/apps/playback.c?r1=1.113&r2=1.114 |
21:19:22 | amiconn | linuxstb: %fc does work? |
21:19:51 | linuxstb | Yes - %fc (current track) seems to work for me, but %Fc doesn't - it always displays "???". |
21:20:04 | amiconn | Ah, yes |
21:20:31 | amiconn | This must be caused by the conversion to multi-conditionals (a la switch()) |
21:20:54 | linuxstb | The "bug" was introduced with the change I've just linked to. |
21:21:11 | amiconn | ...and by the fact that one field in the trackinfo is used for 2 purposes |
21:21:31 | amiconn | codectype has nothing to do with the load status, imho |
21:21:36 | linuxstb | I agree. |
21:22:11 | linuxstb | But I'm curious if there is another bug as well - why did Linus put this issue on the ReleaseTodo page? |
21:22:12 | Slasheri | linuxstb: hmm, i think that zero as codectype means that file is not yet buffered at all |
21:22:24 | Slasheri | so it's important to keep that assigment |
21:22:25 | amiconn | Also, the codec type is metadata supplied by the parser, hence to be stored in tracks[trackno].id3.codectype (like it is) |
21:22:43 | linuxstb | amiconn: Exactly. |
21:22:48 | amiconn | ...but the codec load status is playback engine data and has nothing to do with the id3 sub-structure |
21:23:37 | amiconn | Should be something like tracks[trackno].codec_loaded or so, as a boolean |
21:23:57 | Slasheri | that was also why codec type zero meant "ERR" but now it's just "unknown codec" |
21:24:56 | * | tvelocity eimai gay |
21:24:58 | amiconn | Even with this assignment %Fc wouldn't work right |
21:25:39 | linuxstb | In what way? |
21:26:12 | * | tvelocity never leave your keyboard exposed in public... |
21:26:13 | Lear | no, get_tag in wps-display should return null for codectype 0, I think... |
21:26:32 | | Join San [0] (n=Test@212.2.172.82) |
21:26:34 | amiconn | This would be weird |
21:26:47 | amiconn | ...and %Fc still wouldn't work |
21:27:25 | amiconn | At least it wouldn't work at the same time as the other next_track tags |
21:27:31 | Lear | would display nothing rather than "???" at least. :) |
21:27:46 | linuxstb | It's impossible for a track being played to have an unknown codec.... It's more like "Not yet known", and only applicable to the next track. |
21:28:04 | linuxstb | So %fc will always have a valid value. |
21:28:22 | amiconn | I'd rather change it the way I suggested earlier |
21:28:39 | amiconn | The current method mixes playback engine status info with metadata info |
21:28:47 | linuxstb | amiconn: I agree 100% with that. |
21:29:37 | Lear | Ah, playback.c sets codectype to 0 just after reading the info for the next track, wonder why... |
21:30:05 | linuxstb | because codectype is used for multiple reasons... |
21:31:10 | Lear | yes, as an indicator that the codec is loaded... |
21:33:58 | | Quit DangerousDan (Read error: 104 (Connection reset by peer)) |
21:36:31 | | Join silencer [0] (n=silencer@zen.via.ecp.fr) |
21:36:35 | | Quit silencer (Client Quit) |
21:37:41 | preglow | i think i'll merge upsample and downsample |
21:38:15 | preglow | hmm |
21:38:21 | preglow | might one of the arrays to be resampled be in iram? |
21:39:55 | Lear | yes, resample buf is, buffer from codec is likely to be... |
21:40:06 | preglow | hmm |
21:40:17 | Lear | (unless it has been converted, in case it is known to be in iram) |
21:40:18 | preglow | so there might be some small point in letting downsampling be in-place |
21:41:02 | Lear | I don't see it... :) |
21:41:06 | preglow | well |
21:41:08 | preglow | iram accesses are fast |
21:42:43 | Lear | and the resample buf is in iram, so you don't gain anything... |
21:43:07 | linuxstb | I'm not sure how many codecs put the pcm data in IRAM. FLAC does, but what about mpa and vorbis? |
21:44:28 | linuxstb | AC3/A52 has it in IRAM. WAV doesn't (but could easy be changed to). |
21:45:01 | linuxstb | WAVPACK does. |
21:45:26 | Lear | mpa and vorbis too. |
21:45:53 | amiconn | Someone should check out the extended wav codec patch and commit it |
21:46:08 | Lear | I plan to, after feature freeze. |
21:46:13 | amiconn | (Someone with some test data and/or some time to do it) |
21:46:23 | Lear | (Because then I plan to change metadata.c a lot) |
21:46:35 | linuxstb | I have some time, but no test data. But I've read the patch, and it seems to be good. |
21:46:35 | Lear | And I have created a bunch of test files using sox... |
21:47:22 | linuxstb | preglow: It looks like the answer is that the PCM buffer passed to pcm_insert() is always in IRAM. |
21:48:00 | linuxstb | With the exception of WAV (at the moment), and my ALAC decoder - but I may be able to fix that. |
21:48:59 | | Quit Moos (Read error: 104 (Connection reset by peer)) |
21:49:10 | | Join Moos [0] (i=Moos@m29.net81-66-158.noos.fr) |
21:52:55 | | Join XavierGr [0] (n=XavierGr@ppp14-adsl-175.ath.forthnet.gr) |
21:55:48 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
22:00 |
22:00:52 | | Quit matsl (Remote closed the connection) |
22:01:22 | preglow | perhaps i should try making downsample in place, then |
22:01:48 | preglow | but anywho, need to finish this first |
22:03:08 | | Join TCK- [0] (i=TCK@85-210-23-51.dsl.pipex.com) |
22:03:21 | | Quit Hadaka ("great things are afoot.") |
22:04:07 | *** | Saving seen data "./dancer.seen" |
22:07:02 | | Quit XavierGr () |
22:09:01 | | Join [1]Moos [0] (i=Moos@m29.net81-66-158.noos.fr) |
22:09:01 | | Quit Moos (Read error: 104 (Connection reset by peer)) |
22:09:04 | | Nick [1]Moos is now known as Moos (i=Moos@m29.net81-66-158.noos.fr) |
22:19:31 | | Quit TCK (Read error: 110 (Connection timed out)) |
22:29:08 | | Quit San () |
22:37:01 | | Quit dpassen1 () |
22:37:03 | | Join muesli- [0] (i=muesli_t@Bbcb0.b.pppool.de) |
22:38:25 | linuxstb | preglow: Do you have any way of measuring codec performance? |
22:40:49 | Lear | I have a hack for vorbis... :/ |
22:41:10 | linuxstb | To do what? |
22:41:22 | Lear | measure codec performance |
22:42:21 | linuxstb | How does it work? |
22:43:45 | Lear | It's based on the old xxx2wav files, so I just took the vorbis codec, made it a plugin, added some stuff to time things and removed the stuff to write the data to the pcm buffer. |
22:45:20 | linuxstb | That's what I was thinking. But there must be a better way. |
22:46:30 | | Quit Lear ("Chatzilla 0.9.68.5.1 [Firefox 1.0+/undefined]") |
22:46:59 | | Join bagawk [0] (i=1000@unaffiliated/bagawk) |
22:53:12 | muesli- | re |
22:53:18 | t0mas | hi |
22:53:37 | muesli- | hi t0mas |
23:00 |
23:13:48 | | Quit Zagor ("Client exiting") |
23:14:05 | ]RowaN[ | guys is it possible in theory to build a kinda of connector into an h120 so that you can replace the hd with an sd card, or smaller form factor hd? |
23:14:16 | t0mas | good night :) |
23:14:37 | t0mas | ]RowaN[: I think there is... but I don't know if the controller can handle it |
23:15:02 | ]RowaN[ | the controller is some kinda of hardware controlled device? |
23:15:13 | muesli- | rowan..there are max 4gb of sc-card space possible.. |
23:15:21 | muesli- | dunno if that will make sense |
23:15:41 | ]RowaN[ | what do you mean possible, what is limiting it? |
23:16:14 | muesli- | reckon there no bigger than 4gb on the market |
23:16:17 | muesli- | are |
23:16:36 | t0mas | ]RowaN[: jup, the controller is a hardware device |
23:16:38 | ]RowaN[ | eh? ive seen 12gig sd cards, well read about them |
23:16:40 | t0mas | it "controls" the disk |
23:17:05 | t0mas | and it should be able to handle some memorycards if they're plugged in a memcard->IDE adapter |
23:17:28 | crwl | CF cards should work without problems, no? |
23:17:47 | ]RowaN[ | in a few years time i will replace the hd with a 100gb card then hehe, will be nice and cheap |
23:17:48 | crwl | because their interface is essentially ATA |
23:18:03 | ]RowaN[ | i'd like to think a better mp3 player would be out by then, but its doubtful, the way things are going |
23:18:41 | muesli- | 12gig sd lol..are you donald trump? ;) |
23:19:00 | ]RowaN[ | i didnt say i'd buy one! |
23:19:26 | muesli- | ;) |
23:19:32 | ]RowaN[ | http://www.photographyblog.com/index.php/weblog/comments/12gb_compact_flash_only_14900/ |
23:19:41 | ]RowaN[ | $14900 |
23:20:02 | ]RowaN[ | not sure the date of that article tho, should be cheaper now |
23:20:08 | muesli- | maybe i could get discount if i take 3 ^^ |
23:20:22 | ]RowaN[ | ah March 18, 2004 |
23:21:38 | ]RowaN[ | whats the name of that theory thing which predicts the rate at which processor speed will increase over time |
23:21:46 | ]RowaN[ | some guys name |
23:21:52 | ze | moore isn't it? |
23:21:56 | ]RowaN[ | ah yea |
23:21:57 | ze | moore's law i think |
23:22:08 | ze | which isn't a law, just an observation |
23:22:15 | ]RowaN[ | u know in a few years time you'll be going.. 12gig flash player? thats crap, ive got a 40tb hd player |
23:22:38 | ze | and many think its actually doing more to dictate the rate these days, than really predicting it |
23:22:44 | ]RowaN[ | its a prediction, based on an observation |
23:24:27 | | Join paugh [0] (n=pete@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
23:24:49 | ]RowaN[ | bah stupid cpu overheating |
23:24:58 | ]RowaN[ | WHY did i change a perfercly good fan/heasink!! |
23:25:27 | wubbla | are there any new successes concerning the h300 port? |
23:25:31 | ze | http://en.wikipedia.org/wiki/Moore's_law |
23:25:54 | ]RowaN[ | 3ghz pentium now idles at 60.C/ (150 F), and shoots up to 74.C when i run someone cpu intensive |
23:26:47 | OnkelJonas | if music is still released in the same 'quality' as today, having a 40TB player is a joke |
23:26:59 | muesli- | moore's law its about the development of computing speed and not about prices :p |
23:27:15 | ]RowaN[ | a 20tb partition would be used for porn =p |
23:27:27 | ]RowaN[ | i didnt say it was about prices |
23:27:48 | ]RowaN[ | it just popped into my head when i was thinking about prices |
23:27:52 | OnkelJonas | sure ... but then it would have to be a video player to make sense |
23:28:05 | ]RowaN[ | it would have a projector lens in it =] |
23:28:13 | ]RowaN[ | theres probably a similar law about prices |
23:28:13 | OnkelJonas | unless you just have to carry 20TB of pr0n on you at all times |
23:29:08 | bagawk | pike, Hello :) |
23:29:09 | OnkelJonas | depending on your school of thought, prices are either determined mainly by supply/demand, or by monopoly pricing schemes... |
23:29:23 | ]RowaN[ | is there a "codec" so u can play sacd rips on a computer? |
23:29:36 | pike | bagawk ;) it's based on libmad |
23:29:39 | ]RowaN[ | i call it, ROWANS LAW =] |
23:29:42 | OnkelJonas | when there are monopolies, manufacturing costs doesnt matter wrt product pricing :( |
23:30:10 | OnkelJonas | "the stuff ]RowaN[ wants has to be cheap" :P |
23:30:24 | ]RowaN[ | if only that was law |
23:30:27 | ]RowaN[ | ahmen |
23:31:43 | ]RowaN[ | <muesli-> moore's law its about the development of computing speed and not about prices :p |
23:31:44 | OnkelJonas | ROFL... 40TB is more than 50.000 albums without any compression |
23:31:45 | ]RowaN[ | yes it is... |
23:31:52 | ]RowaN[ | Moore's law is the empirical observation that at our rate of technological development, the complexity of an integrated circuit, with respect to minimum component cost will double in about 18 months. |
23:32:38 | ]RowaN[ | you mean in wav format? future music will take up more space, it'll be like, HD, 20 channel surround |
23:32:45 | OnkelJonas | i dont think thats the cost in $ - but the "cost" in no. of components/squareinch |
23:33:11 | ]RowaN[ | yes, cost |
23:33:18 | OnkelJonas | you will still be dreaming that sweat dream when you sit deaf in your retirement home |
23:33:26 | OnkelJonas | ;) |
23:33:42 | ]RowaN[ | sweet dreams for me |
23:34:31 | preglow | linuxstb: no way yet, no, i'm kind of busy rightnow |
23:35:14 | ]RowaN[ | so anyone know about SACD.. is there a codec, does anyone release rips? not interesting in sacd warez just interested to know hehe |
23:35:25 | linuxstb | preglow: No problem. Are you planning something? |
23:35:58 | OnkelJonas | speaking of SACD (which afaik is dying slowly but surely)... does any of the big companies have plans for future audioformats atm? |
23:36:00 | linuxstb | ]RowaN[: AFAIK, computer CD/DVD drives can't read SACD data. |
23:36:28 | ]RowaN[ | yup they cant, but surely optical output of a sacd player could go to pc |
23:36:35 | linuxstb | DVD-Audio can now be ripped (using a hacked version of a Windows player). |
23:36:57 | ze | yeah when your music is lossless 32bit 192khz 16-channel 3D surround, thats a lot less than 50000 albums |
23:36:59 | linuxstb | ]RowaN[: Optical outputs of high-resolution audio players (SACD/DVD-Audio) are encrypted. |
23:37:03 | OnkelJonas | does dvd-audio have a future (besides its niche appearance) |
23:37:28 | linuxstb | You tell me :). I personally like it because I can put 4.5GB of 44.1KHz WAV files on a single disc. |
23:37:28 | ]RowaN[ | since when did encryption ever stop anyone? |
23:37:29 | OnkelJonas | but who will make those recordings ze? |
23:37:37 | ze | OnkelJonas: who won't? |
23:37:53 | linuxstb | OnkelJonas: They have already been made - on high resolution analogue tapes. |
23:38:04 | ze | 24bit 96khz/192khz is already the internal digital standard in the industry |
23:38:23 | linuxstb | But a lot of people argue that 44.1KHz/16-bit is already good enough for almost all humans. |
23:38:29 | OnkelJonas | sure... but do you seriously see them being published outside some rare niche stuff any time soon? |
23:38:36 | ze | and yeah analog recordings can always be digititized to any depth and rate |
23:39:01 | ze | linuxstb: there's well known advantages to 24bit |
23:39:08 | ze | vs 16 |
23:39:16 | linuxstb | The consumer seems happy with MP3/AAC at the moment, so it seems unlikely. |
23:39:16 | ze | higher sampling rates are more arguable |
23:39:49 | | Join [1]Moos [0] (i=Moos@m29.net81-66-158.noos.fr) |
23:39:59 | ze | but lots of people argued that nobody needed more than 16bit color too |
23:40:01 | OnkelJonas | besides... considering the "quality" of audio equipment in the average home its unlikely to make much of a difference anyway |
23:40:07 | ze | but just try looking at 16bit gradients |
23:40:14 | | Quit Moos (Read error: 104 (Connection reset by peer)) |
23:40:14 | | Nick [1]Moos is now known as Moos (i=Moos@m29.net81-66-158.noos.fr) |
23:40:30 | ]RowaN[ | u guys heard of XRCD (http://us.yesasia.com/en/brPrdDept.aspx?section=music&code=c&did=3256)? its not a new format at all, just a well mastered CD.. kinda like the CD equivalent of a "SuperBit" DVD movie |
23:40:39 | ]RowaN[ | average homes? yuk! |
23:40:56 | ]RowaN[ | average people shouldnt have a say in the future of music quality =p |
23:41:05 | ze | heh |
23:41:32 | ze | i'd hope the quality of equipment improves by the time we reach 40TB |
23:41:38 | ]RowaN[ | well, you have to assume its well mastered.. u pay your money then find out |
23:41:48 | OnkelJonas | hahaha... XRCD = teh funny |
23:42:07 | ze | music should be well mastered whatever format its on |
23:42:18 | linuxstb | I'm sure the recording industry hate CDs because they are not "secure". So they are happy to push new formats - as are hardware manufacturers. |
23:42:23 | ]RowaN[ | should, i love that word |
23:42:39 | OnkelJonas | you gotta admire an industry that can make crappy mastering the standard, and then release properly mastered CDs for a premium :D |
23:42:48 | ]RowaN[ | hehe |
23:42:58 | ]RowaN[ | thems the breakz kids |
23:43:27 | ze | all the while telling you how important it is to get your stuff mastered by a professional |
23:43:38 | ze | and how virtually impossible it is for you to do a decent job of it yourself |
23:44:30 | ]RowaN[ | cds used to say AAA, AAD, DDD or whatever on them to indicate a snippet of the mastering process.. dont tend to see that these days |
23:44:50 | ]RowaN[ | or is it just on classical stuff? |
23:45:00 | ]RowaN[ | wow http://www.xrcd.com/ heh |
23:45:25 | | Quit Moos (" HydraIRC -> http://www.hydrairc.com <- Try something fresh") |
23:45:56 | ze | yeah most cd's released in the 80's had that |
23:46:40 | ]RowaN[ | maybe at some board meeting they had the idea that telling the consumer how sloppy the mastering was might adversly affect sales |
23:47:37 | OnkelJonas | can you get lossless in the itunes store now? |
23:47:55 | ]RowaN[ | i think so, not that i'd ever use itunes |
23:48:12 | ]RowaN[ | apple have their own lossless format dont they |
23:48:25 | ze | it wasn't about sloppyness, it was just indicating what domain each part of the process took place in |
23:48:26 | OnkelJonas | yea |
23:48:49 | ]RowaN[ | AAA is pretty sloppy aint it |
23:48:53 | ze | why? |
23:49:01 | ]RowaN[ | compared to DDD |
23:49:06 | OnkelJonas | if itms starts pushing lossless (hopefully at a minimal premium) more people will start caring about it |
23:49:06 | ze | what're th 3 parts? |
23:49:10 | ze | recording, mastering, and ? |
23:49:15 | ze | or is it recording, mixing, and mastering? |
23:49:21 | ]RowaN[ | no idea |
23:49:25 | crwl | recording, mixing and mastering |
23:49:36 | ze | lots of people still do it all analog |
23:49:50 | ]RowaN[ | jesus, we're not missing out on anything with XRCD, unless you like tony bennet or obscure jazz |
23:50:03 | crwl | (never seen AAA cd's though - is it possible to do a CD mastering process in an completely analog way?) |
23:50:03 | ze | among audiophiles and purists (which make up a lot of the recording industry), "digital sucks" |
23:50:15 | OnkelJonas | nonono... its about the mastering process: Aspirin, Aspirin, Doughnut |
23:50:22 | ze | crwl: sure |
23:50:27 | OnkelJonas | more As = more problems |
23:50:47 | ze | analog isn't inherently problematic, and digital isn't without its issues |
23:51:18 | OnkelJonas | there must be a digital stage at the end... |
23:51:41 | ze | mastering is just adjusting levels, frequency content, and misc stuff like that, of a final mix, to try to get it to be as consistent as possible on a wide range of playback equipment |
23:51:52 | ze | or to maximize volume, or really numerous project-specific goals |
23:52:34 | ze | for mainstream music, there's lots of dynamics compression, etc... for classical, very little |
23:52:46 | OnkelJonas | true - but there will still be a degradation of quality (/amount of audio information left from original) when moving through several analog stages, something that doesnt have to be the case with digital |
23:52:47 | ze | but it can quite easily be done in the analog domain |
23:53:17 | ze | and then the results can be digitally sampled |
23:53:28 | ze | OnkelJonas: not necessarily, and it depends on the equipment |
23:53:31 | ze | and the processes |
23:53:31 | | Quit DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
23:54:00 | OnkelJonas | how are you going to move an analog signal through a cable without loosing information? |
23:54:26 | ze | short cables, proper impedance matching |
23:55:09 | ze | and keep in mind the goal of music isn't ultimate fidelity, which is often undesired as it sounds rather sterile, but being humanly percieved as sounding good musically |
23:55:13 | OnkelJonas | there will still be some loss - of course it can become an academic issue since it can be inaudible amounts, but still... |
23:55:20 | OnkelJonas | agreed :) |
23:55:39 | ze | a lot of people prefer analog precisely for the ways in which it distorts the signal |
23:55:40 | ]RowaN[ | lets not fight lets all be friends =p |
23:55:54 | ze | they call it 'warmth' |
23:56:06 | ]RowaN[ | a dsp could add that warmth heh |
23:56:17 | ze | and there's a lot of people doing a lot in the analog domain before transferring to digital just to get that warmth |
23:56:50 | ze | there's a lot of things that digital processing isn't very good at that's trivial in an analog circuit |
23:57:13 | ze | its not that easy to digitally emulate the analog warmth of a particular circuit |
23:57:23 | ze | you have to account for a lot of factors |
23:57:24 | | Join TCK [0] (i=TCK@85-210-22-238.dsl.pipex.com) |
23:57:26 | OnkelJonas | IMO "mastering" is all about changing the audio to whatever the endproduct should be like... so if that means feeding it through a dead crocodiles hindlegs I dont give a s### |
23:58:08 | ze | OnkelJonas: right |
23:58:08 | ze | hehe |
23:58:31 | ze | you have to also realize, the more processing you do to a digital signal, the more you risk aliasing and various digital oddities like that |