Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2017-02-11

00:03:59 Quit scorche (Read error: Connection reset by peer)
00:08:05YstI remember where I know that name from now. It used to be used as an identifier in the Lua of Minetest, though I don't think that it is any more.
00:13:02 Join scorche [0] (~scorche@rockbox/administrator/scorche)
00:34:52jhMikeS__builtin: it looks okay now. thanks
00:42:55 Quit skapazzo (Quit: leaving)
00:51:01 Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51)
00:58:23 Quit Moarc (Ping timeout: 258 seconds)
00:58:57 Join Moarc [0] (~chujko@a105.net128.okay.pl)
01:00
01:00:07***Saving seen data "./dancer.seen"
01:09:12 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net)
01:12:54 Quit Bray90820 (Remote host closed the connection)
01:27:16 Join Bray90820 [0] (~bray90820@173-25-204-30.client.mchsi.com)
01:38:12BilgusJhMikeS is your 1556 patch ready to go?
01:42:10 Quit ender` (Quit: The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts.— Bertrand Russell)
01:43:39Bilgusdo I just call root_unmount_volume( and unmount drive 0 and then root_mount_path( with my new path?
01:54:05jhMikeSBilgus: regarding the second thing: wot?
01:55:29jhMikeSregarding the first thing: 1) needs to be cut back for targets that don't need to mount various directories 2) The sim needs to be worked on
01:56:02Bilgusok so i'll give you a for instance I just booted My bootdata indicates volume 1 is boot drv and I have a redirect to /<1>/test/.rockbox what do I need to do?
01:56:04jhMikeSBilgus: why do you need to unmount anything first? that sounds weird
01:56:54BilgusOh I assumed you had to unmount before you added your new one then re-enumerate
01:56:57jhMikeSif you want to switch mounts, then unmount the root and mount something else there
01:57:12jhMikeSyou do, yes
01:59:08jhMikeSbut yeah, if you unmount the volume that also has the root it gets that too
02:00
02:00:30Bilgusgets what too?
02:00:35jhMikeSI didn't make it so you can just unmount the root itself but that wouldn't be much trouble actually
02:01:43jhMikeSBilgus: if the volume you unmount happens to be the one that contains the mounted root directory, it unmounts the root too
02:02:39Bilgusok so as far as all the streams and file functions what Do i need to do to 'emulate' <1>/test.rockbox as the main directory, atm in this scenario it will write to <0>/.rockbox
02:03:34jhMikeS<0> is always volume 0
02:03:40BilgusI don't necessarily want to unmount the true root
02:05:26Bilgus<Allow mounting of any directory as the root directory.> that would be <1>/test/.rockbox
02:06:21jhMikeSthus "/foo" really accesses "/<1>/test/.rockbox/foo"
02:07:27Bilgusok so I would mount <1>/test and /.rockbox would actually be '<1>/test.rockbox'
02:07:59Bilgusok so I would mount <1>/test and /.rockbox would actually be '<1>/test/rockbox'
02:08:14Bilgus.rockbox' grr
02:08:19jhMikeSheh
02:08:30jhMikeSyes
02:10:21Bilgusok so All I need to do then is pass root_mount_path() my new path and flags?
02:11:38jhMikeSreally, those should not be called directly. disk_mount_all are supposed to call that stuff
02:13:04jhMikeSif you change the macro to point to a string that returns the correct path, it should get done at firmware boot
02:14:36Bilgusah ok so RB_ROOT_CONTENTS needs to mount to my <1>/test directory?
02:14:45Bilgussorry point*
02:15:14jhMikeSyes
02:16:26jhMikeSit doesn't have to be entirely static at compile time as long as a path is contructed before disk_mount_all is called during init
02:16:47Bilgusand what do I do with RB_ROOT_VOL_HIDDEN(v) in this scenario pass 0?
02:17:32jhMikeSreplace that macro if there are volumes you don't want showing up in the browser. it should return true for any v you don't want to see
02:17:59jhMikeSright now it just defaults to hiding 0, since that's how it is for most
02:20:12Bilgusok I think I have it I'll try it out tomorrow Thanks.
02:43:34 Quit mutnai (Quit: Page closed)
03:00
03:00:09***Saving seen data "./dancer.seen"
03:00:24fs-bluebotBuild Server message: 3New build round started. Revision 6436c6e, 255 builds, 17 clients.
03:11:01 Quit ZincAlloy (Quit: Leaving.)
03:11:22fs-bluebotBuild Server message: 3Build round completed after 657 seconds.
03:11:23fs-bluebotBuild Server message: 3Revision 6436c6e result: All green
03:23:05__builtindoes anyone know why ARM doesn't print a backtrace on a panic?
03:23:36jhMikeSit's supposed to (bt:), sometimes it works
03:26:53jhMikeSnvm, not panic :)
03:31:37__builtinhuh, so it's not intentionally disabled or anything
03:42:47 Quit Bray90820 (Read error: Connection reset by peer)
03:43:25 Join Bray90820 [0] (~bray90820@173-25-204-30.client.mchsi.com)
03:47:08 Quit Amboyna (Ping timeout: 264 seconds)
03:50:43 Join TorC [0] (~TorC@fsf/member/TorC)
04:00
04:18:04 Quit Moarc (Ping timeout: 240 seconds)
04:19:13 Join Moarc [0] (~chujko@a105.net128.okay.pl)
05:00
05:00:13***Saving seen data "./dancer.seen"
05:43:27 Quit alexweissman (Remote host closed the connection)
05:44:42 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net)
06:00
06:53:07 Quit alexweissman (Remote host closed the connection)
06:53:47 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net)
06:58:39 Quit TheSeven (Ping timeout: 245 seconds)
06:59:08 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
07:00
07:00:07 Quit furrywolf (Ping timeout: 252 seconds)
07:00:17***Saving seen data "./dancer.seen"
07:19:49 Quit advcomp2019__ (Ping timeout: 258 seconds)
07:20:36 Join advcomp2019 [0] (~advcomp20@65-131-154-48.sxct.qwest.net)
07:20:36 Quit advcomp2019 (Changing host)
07:20:36 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
07:29:31 Quit pixelma (Quit: .)
07:29:32 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
07:32:54 Join pixelma [0] (~pixelma@rockbox/staff/pixelma)
07:32:55 Join amiconn [0] (~amiconn@rockbox/developer/amiconn)
07:59:24*dys found another aspect where the cf->sdcard adapter ignores the spec
08:00
08:00:23dysremoving supply power makes it turn 150mW into heat through its data pins
08:00:31*dys needs to patch ata.c even more
08:18:32 Quit bluebrother (Ping timeout: 240 seconds)
08:18:58 Quit fs-bluebot (Ping timeout: 255 seconds)
08:20:31 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
08:33:07 Join fs-bluebot [0] (~fs-bluebo@xd9bafb59.dyn.telefonica.de)
08:37:23 Quit PurlingNayuki (Ping timeout: 245 seconds)
09:00
09:00:21***Saving seen data "./dancer.seen"
09:34:02 Join lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr)
09:42:09lebelliumBilgus: The Rocker turned off due to low battery a bit sooner as I expected. I was sleeping. It stopped at the 130th song. According to MP3tag, that's 9,5 hours
09:43:02lebelliumsooner than*
10:00
10:52:14 Join ender` [0] (krneki@foo.eternallybored.org)
11:00
11:00:22***No seen item changed, no save performed.
11:31:37 Quit JanC (Ping timeout: 276 seconds)
11:33:37 Join JanC [0] (~janc@lugwv/member/JanC)
12:00
12:16:33 Join krabador [0] (~krabador@unaffiliated/krabador)
12:16:40 Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz)
12:43:04 Join StaticAmbience [0] (~Quassel@host213-1-11-77.range213-1.btcentralplus.com)
13:00
13:00:26***Saving seen data "./dancer.seen"
13:07:40 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:e447:1a5c:787c:e470)
13:13:48 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627)
13:23:34 Join robertd1 [0] (~root@186-90-12-124.genericrev.cantv.net)
13:49:28 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
13:51:27 Quit jhMikeS (Ping timeout: 240 seconds)
13:56:30 Quit paulk-collins (Remote host closed the connection)
13:58:04 Quit pamaury (Ping timeout: 260 seconds)
14:00
14:12:57dysgah, gone again
14:13:13*dys wonders whether pamaury has an idea how to deal with the C++ vtables
14:14:10dysalways when the disassembly is about to get interesting, the calls are obscured
14:20:35dongsyou gotta make a struct to match vtable and change pointer type to that
14:20:54dongsa real cunt to do, too , since struct editing in ida is retarded af
14:24:10Bilgus<lebellium> thats not that bad was that with the screen on buttons unlocked?
14:46:40lebelliumBilgus: display off (on for about 2 min overall), low gain, volume 20/60 with IEM loaded, mostly MP3 VBR V0 and CBR 192 and a few FLAC and MP3 CBR 128 and WMA CBR 128
14:48:16Bilgusah so thats about best case overall does it seem to have a large file buffer or do you think thats with a lot of sd accesses?
14:49:30lebelliumI thought AGPTek meant 10hrs with lossless files and 15hrs with MP3 files
14:49:59lebelliumI'm currently running the benchmark again to see if the battery is better calibrated now
14:50:24lebelliumI don't know about the buffer.
14:51:27lebelliumbut gapless playback doesn't work if you go to the 15 last seconds of the current song and wait for the next song
14:51:33lebelliumwhile it works in Rockbox
14:52:39lebelliumI need to play the whole current song so that next one loads without gap inbetween
15:00
15:00:30***Saving seen data "./dancer.seen"
15:05:08Bilgusah so probably just a lot of sd access
15:08:47lebelliumIt has a 600mAh battery
15:09:13lebelliumeven if the CPU is quite powerful, I'm surprised I don't reach more than 10 hrs with mostly MP3 files
15:09:41lebelliumI hope it's a lack of optimization and that it could be better in Rockbox
15:15:40BilgusI'm sure there is still some wiggle room in there but honestly I don't typically listen to my DAP much more than 8 hrs in a day
15:16:26lebelliumI neither for sure. But I don't want to charge it everyday
15:16:30lebelliumit's not a smartphone!
15:16:58BilgusLOL I have a dumb phone thats one of the reasons its batt lasts 3-5 days
15:17:44BilgusI'm pretty used to charging my DAP daily
15:18:07Bilgusthough it is nice that if I forget it still has a days worth
15:18:26 Quit cc___ (Ping timeout: 256 seconds)
15:19:12Bilgusthats like in the bad old days realizing your batteries were flat in your cd player and spinning the disk to make it so it wouldn't do low batt shutoff LOL
15:26:07 Quit dfkt (Quit: SIC GORGIAMVS ALLOS SVBJECTATOS NVNC.)
15:31:43 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627)
15:33:21 Quit cc___ (Client Quit)
15:33:57 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627)
16:00
16:17:54 Join paulk-aldrin [0] (~paulk@armstrong.paulk.fr)
16:23:46 Join furrywolf [0] (~randyg@m860536d0.tmodns.net)
16:30:39 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
16:38:45 Quit foo|sh (Remote host closed the connection)
16:41:26 Join foolsh [0] (~starchase@162-204-199-234.lightspeed.sbndin.sbcglobal.net)
16:41:52 Quit foolsh (K-Lined)
16:42:31lebelliumpamaury: did you get the authorization to share the firmware and tools for the Rocker?
16:44:02pamaurylebellium: no, they don't want me to publish stuff. I wanted to send a message asking him to do a public firmware release so that everyone can have it but I was unlucky and couldn't reach the forum
16:44:53pamauryHe pointed to the kernel and uboot source code though, those are public and on ingenic website so I guess that's fine. But since I can't reach the forums...
16:45:49pamaurydys: C++ is always a pain to RE. You have to create a structure for the vtable and identify the offset within the table for each function call, it makes tracing much harder. I usually come up with naming convention to make it easier
16:46:18pamauryit's already super annoyin with like IDA so I can't imagine doing it by hand
16:46:22lebelliumpamaury: he replied on the forum that he would take my improved translation so I expect them to release a new firmware sooner or later anyway
16:47:16pamaurylebellium: ok, then almost all the binaries ar in the firmware upgrade, afaict it's just an iso with several files in it. The only extra I have is a tool to write the flash over usb I think, in Chinese
16:47:27pamaurywith almost no doc
16:48:12lebelliumYes, they want you to put the fw on the sdcard and select the "upgrade firmware" setting
16:48:28lebelliumthey don't want the normal user to use a flashing tool
16:48:57pamauryyes, that's the sane way of processing. But the thing is that I have no info on the firmware upgrade process, I only have the firmware file and I can only guess how the process works
16:49:06__builtinpamaury: the forums seem to work now
16:50:10pamauryactually the link to the source code of the kernel is http://www.ingenic.com/en/?newsshow/tp/228/id/113.html
16:50:22pamaurywhich is just the standard ingenic page explaining to get the git repo
16:50:35lebelliumI assume you'll gathering all those links on the wiki page?
16:50:52lebelliumgather*
16:51:59pamauryI am travelling and super busy until friday, I don't have the time right now
16:57:44pamauryand there is only one link so far, it's the ingenic one above :-p
16:58:27lebelliumI mean also the programing manual and all the stuff
17:00
17:00:32***Saving seen data "./dancer.seen"
17:01:08pamauryI'll upoad the PM that I found on the ingenic website. As for the other stuff, it's useless. The bluetooth core "datasheet" I got is 2 pages long, only marketing bullshit
17:01:48lebelliumok
17:03:48pamaurythe datasheet for the codec is availale on cirrus website: https://d3uzseaevmutz1.cloudfront.net/pubs/proDatasheet/CS42L51_F2.pdf
17:03:56pamauryhttps://www.cirrus.com/products/cs42l51/
17:10:58*__builtin just found a horrendous bug in xworld
17:29:09 Join skapazzo [0] (~skapazzo@151.9.205.1)
17:48:09 Join dfkt [0] (~dfkt@unaffiliated/dfkt)
19:00
19:00:36***No seen item changed, no save performed.
19:46:14 Quit pixelma (Quit: No Ping reply in 120 seconds.)
19:47:33 Join pixelma [0] (~pixelma@rockbox/staff/pixelma)
20:00
20:09:12dyspamaury: can you add me as a contributor to the repo onkyo_teac_tools?
20:09:31dysi found the code that does things with the header before the first boot block
20:12:12 Quit WakiMiko (Quit: WeeChat 1.8-dev)
20:13:47 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko)
20:20:48pamaurydys: what is your email address/github account ?
20:21:30dysanse1 (the only watcher of the project :-)
20:22:47pamaurydys: you should have received an invitation now
20:23:27dysthanks!
20:24:07pamaurywhat do the bytes before the header encode ?
20:24:15pamauryand what about the checksum at the end ?
20:25:35dysmost of them are trivial info (version, build, date, time)
20:26:12dysi'm still chewing on the checksum
20:30:57 Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51)
20:34:44pamaurydys: feel free to update the repo with what you have already
20:35:33pamauryas you might have seen, I usually have the tool print info about all fields when the debug switch is enabled
20:35:51pamaurycould be cool if you add debug output similarly for those other fields
20:36:23dysI found some inconsistencies when running on different update images…
20:36:36dysdon't want to push things that obviously need a fixup…
20:36:48pamauryok
21:00
21:00:06 Quit robertd1 (Ping timeout: 240 seconds)
21:00:38***Saving seen data "./dancer.seen"
21:05:15 Quit StaticAmbience (Quit: No Ping reply in 180 seconds.)
21:14:23 Quit mutnai (Ping timeout: 260 seconds)
21:14:53 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com)
21:19:40 Quit paulk-aldrin (Quit: Leaving)
21:19:41 Join StaticAmbience [0] (~Quassel@host213-1-11-77.range213-1.btcentralplus.com)
21:20:24 Quit jhMikeS ()
21:20:59 Join AxelK [0] (~AxelK@p5790E9D9.dip0.t-ipconnect.de)
21:21:48AxelKHi there.
21:22:31AxelKI would like to report a strange behavior with rockbox on my Sansa ClipZip when playing certain opus files.
21:22:58AxelKIt lokks like a corner case to me and it is also not 100% reproducible.
21:23:19 Quit WakiMiko (Quit: WeeChat 1.8-dev)
21:23:36AxelKThe only thing that seems to make the error more likely to appear is the bit rate used for encoding of the opus file.
21:23:52AxelKThe lower the bit rate, the more likely the problem appears.
21:23:55 Quit StaticAmbience (Client Quit)
21:24:29AxelKFiles with 32Kbit seem to give a good "chance" of getting hit by the problem.
21:24:50AxelKwith 64Kbit the problem is at least very rare
21:25:19AxelKYou start playing one of those files and within a short time (few seconds) you hit fast forward
21:25:20 Join StaticAmbience [0] (~Quassel@host213-1-11-77.range213-1.btcentralplus.com)
21:25:52AxelKThe system might crash wit the need of a hard reset (pressingpower button for ca. 20 sec)
21:26:02AxelKError message on the screen reads
21:26:08AxelK*PANIC*
21:26:14AxelKStkov codec
21:26:30AxelKpc: 3006CAFAC sp:3
21:26:40AxelKcorrection
21:26:51AxelKpc: 3006CFAC sp:3
21:27:03AxelKA: 30098158
21:27:06AxelKbte end
21:27:09AxelKbt end
21:27:30AxelKAnother instance this crash might happen though a lot less often
21:27:36AxelKyou listen to a opus file
21:27:45AxelKyou turn off the CliZip
21:28:06AxelKyou turn it on again some time later and try to resume
21:28:35AxelKso the respective file should be played from where you left (or a few seconds before that point)
21:29:14AxelKsometimes the player crashes with the same message (OK, not shure if it is the excat same hex numbers)
21:29:48AxelKbut the *PANIC* Stkov codec and bt end are being shown on the screen after the crash
21:30:39AxelKAs said before, the second error is much more harder to reproduce than the one where you use fast forward directly after starting to play an opus file
21:31:40AxelKThe problem does not appear when letting the file play for some time, 30 seconds to 1 minute seem to be enough and then hitting fast forward
21:32:33AxelKso maybe some information about the length of the file or some indexing information might not be fuly available and if so the crash appears
21:32:56 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko)
21:34:00AxelKI tried opus files encoded with "opusenc" (from opus-tools package) and with ffmpeg and the "-acodec libopus" option, same result
21:35:17AxelKMaybe some developer will read this later and in any case it is now in present in the archive at https://www.rockbox.org/irc/ (or at least it will be there soon)
21:35:20AxelKbye
21:35:23 Quit AxelK (Quit: Verlassend / Leaving)
21:36:19 Part Yst ("<https://y.st/>")
21:48:02 Join AxelK [0] (~AxelK@p5790E9D9.dip0.t-ipconnect.de)
21:48:23AxelKSorry, forgot some important information.
21:50:13AxelKI am running the development branch of rockbox, atm release a4dc244 from february 10th 2017, so it is not a problem of an old release
21:51:00AxelKI have two ClipZip players, a 4GB and a 8GB model, both are affected
21:52:08 Quit AxelK (Client Quit)
21:52:22 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com)
21:58:32 Join qorx [0] (57673c1f@gateway/web/freenode/ip.87.103.60.31)
22:00
22:00:11 Quit WakiMiko (Quit: WeeChat 1.8-dev)
22:01:26 Quit pamaury (Ping timeout: 240 seconds)
22:01:59qorxHi, my clip+ all of a sudden messed up the sound.. It sounds like hearing music through a tin can, very metalic noise and no bass whatsoever
22:02:30qorxIt gets marginally better if I tweak the balance in the settings either way
22:02:50 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko)
22:03:01 Quit WakiMiko (Client Quit)
22:03:14qorxIf I leave it a 0, it's bad and can't hear decently
22:04:20qorxI've never heard of this issue with clip+'s, does anyone know anything about that?
22:05:10 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko)
22:11:10 Quit WakiMiko (Quit: WeeChat 1.8-dev)
22:11:25 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko)
22:11:41 Quit amiconn (Quit: No Ping reply in 64 seconds.)
22:13:00 Join amiconn [0] (~amiconn@rockbox/developer/amiconn)
22:15:53 Join saratoga [0] (c036de1c@gateway/web/freenode/ip.192.54.222.28)
22:15:54saratogaqorx: the ground pin on your headphone jack isn't making contact, so you're hearing the L-R signal
22:17:55saratogaAxelK: if you can find a way to reproduce the problem, file a bug report with the instructions and a link to the file in question
22:39:33 Quit qorx (Ping timeout: 260 seconds)
22:49:39 Quit saratoga (Quit: Page closed)
22:50:52 Join qorx [0] (57673c1f@gateway/web/freenode/ip.87.103.60.31)
22:52:59qorxsaratoga: Thanks! That was it, I tested it just now and the sound is normal again upon proper contact. I'll fix properly, many thanks.
22:57:21 Join AxelK [0] (~AxelK@p5790E9D9.dip0.t-ipconnect.de)
22:57:38 Quit qorx (Ping timeout: 260 seconds)
22:59:31AxelKsaratoga: that might e a bit of a problem, the files where it is somehow reproducible are self encoded opus files with 48 or 32 Kbit
23:00
23:00:39***Saving seen data "./dancer.seen"
23:00:41AxelKMost of the podcasts in opus format (at least the ones I listen to) use 64KBit and they are very rarely affected
23:02:17AxelKAnother detail that might be important, the files seem to need a certain minimal length, short files of a few seconds or minutes seem to be fine, while podcasts of 1 or 2 hours are more likely to cause the problem
23:03:15AxelKAs I tried to indicate before, it is a rather rare problem and I tried to avoid the word "bug" because it is not really easy to reproduce
23:04:17 Join Quantum1337 [0] (~Quantum13@unaffiliated/n00b81)
23:04:27AxelKthe "best" shot might be to encode some opus file of 1 hour or longer (some podcast) with 32Kbit and try to get hit by that problem playing that file
23:05:17AxelKmeaning, start playing it and quickly after that (i.e. as quickly as possible) try to fast forward
23:06:14AxelKalso the amount of minutes trying to fast forward seems to be a factor, the further you try to get (10 minutes or more), the more likely the player will crash
23:08:39 Quit krabador (Ping timeout: 240 seconds)
23:09:23AxelKThe only thing that makes me think it i not a problem with my encoding software is, that there the problem also apperas with 64Kbit opus files I did not encode myself (although very rarely)
23:10:42 Part Quantum1337 ("Leaving")
23:10:53AxelKand that files produced by two different encoding programs (at least slightly different as they use the same library) show this problem
23:13:34AxelKSo for anyone tryingto reproduce this, take some longer audio file (podcast of 1 or two hours) let's say as an mp3 and run
23:14:05AxelKffmpeg -i the.mp3 -c:a libopus -b:a 32k testfile.opus
23:14:16AxelKand try that file
23:15:02AxelKor if you want to use a file directly encoded with opusenc (which will also use libopus)
23:15:13AxelKget some longer wav file and encode with
23:15:41AxelKopusenc −−bitrate 32k some.wav test.opus
23:18:13AxelKThe version of libopus also does not seem to make a difference, I have files encoded with libopus 1.0.x up to those encoded with 1.1.4 (latest stable release)
23:19:49AxelKmeaning I stumbled upon this (rare) problem quite some time ago, but I did not bother too much as it was more or less difficult to reproduce
23:22:11AxelKBut now I think I have found at least some more details how to make it more likely to trigger this problem
23:22:57AxelKalthough it is still not an easy "here's how to crash your ClipZip in five easy steps"
23:48:03 Quit AxelK (Quit: Verlassend / Leaving)
23:49:04 Join AxelK [0] (~AxelK@p5790E9D9.dip0.t-ipconnect.de)

Previous day | Next day