圆刚Live Gamer HD Lite(GL510E)使用感受 [更新]

前言:

前段时间借出去的梅露露Plus回来了,这游戏自打买了就一直坑着,后来干脆直接借人借了半年多。拿回来之后放PSVTV里面玩,在我的23寸显示器上画面被拉的惨不忍睹。去年在PSVTV玩讨鬼极的时候也没觉得画面这么差,当时和基友也讨论过讨鬼极的画面,结论是KT美工强悍,虽然只有960×544的分辨率,但是拉到23寸1080p显示器上看依旧觉得画面很不错。不过这次梅露露plus似乎达不到讨鬼极的这个效果了。而且我一直以来对玩主机游戏的时候会彻底把我的主显占用这件事儿感到很闹心,虽然有副显在旁边,但是还是免不了切换主显的输入信号来查看某些PC上面的东西。于是这么一折腾,就让我萌生了买一块儿HDMI采集卡的想法。

 

继续阅读圆刚Live Gamer HD Lite(GL510E)使用感受 [更新]

关于联通用户无法加载Steam图片的解决方法

6月初我还在秦皇岛的时候,用秦皇岛联通登录Steam是一切正常的。但是毕业回北京之后,发现用北京联通的时候不能正常加载到Steam的图片,在Firefox里打开代理就能正常加载,于是我也就没理这个事。

这几天发现Steam又到了暑期特惠了,打折还真是狠,然后Steam客户端登录商店依旧是无法加载图片,实在是烦人。

于是打算着手解决一下这个问题。目测是gfw干的好事,但是具体是怎么弄的还得细致分析一下。查看steam网页源代码,取得几个保存css、图片等的域名后,用nslookup进行解析,然后开VPN,清空dns缓存再解析,果然发现结果不一样。看来是dns污染了。

解决办法:

依旧是传统的改hosts文件,位置如下:

c:WindowsSystem32driversetchosts

在文件末尾添加以下内容并保存:

208.64.202.69       store.steampowered.com
203.77.188.253    cdn.store.steampowered.com
203.77.188.254    cdn.steampowered.com
203.77.188.254    media.steampowered.com
63.235.4.133        support.steampowered.com
63.228.223.103    steamcommunity.com
203.77.188.253    cdn.steamcommunity.com

打开cmd,运行以下命令

ipconfig /flushdns

大功告成。

用Zune给WP7系统更新时遇到80072F0D错误的解决办法

刚入手了一台诺基亚的撸妹800,正在各种爽的时候发现,用Zune给系统进行更新的时候,会出现网络错误以及80072F0D的错误号。

于是这个小问题折腾了我好久,最后才发现问题所在。对系统更新需要满足以下几个要求:

  1. PC能够正常访问互联网
  2. 手机要用数据线和PC连接
  3. PC端要开着Zune
  4. 手机自身要能访问互联网

啊啊,没错,我的撸妹800就是因为不满足第四条所以导致更新失败。正好新买的无线路由器也到手了,把撸妹800连上Wifi之后,再从Zune里更新,就一切正常了。

啊,其实并非只有Wifi才可以,手机用2G/3G的数据网络也是可以的。但是我是2G卡而且流量已经用完了,所以在手机里把数据网络给关了,于是就……

基于MPC-HC的10bit播放全攻略 v1.1

目前10bit风头正劲,包括我在内的我周围的好多朋友已经全面转向了10bit压制制程,而且这个季度的新番,也有一些字幕组开始尝试10bit压制。技术总是要向前发展的,正如我们开始大刀阔斧地淘汰rmvb一样,10bit这种新技术也到了开始普及的阶段。普及10bit的理由?码率更低,画质更好,足够具有说服力了。不过很多人可能对10bit的解码播放感到很棘手,问我如何搞定10bit的朋友就已经不下4个了,每次都要把同样的话重复说一遍实在是浪费的一种体现。于是写个文,一可以直接发给搞不定10bit播放的人,二可以当个备忘,一举两得。
(向对本文撰写提供测试帮助的304童鞋表达感谢)
本文谢绝转载,如果有疏漏之处,欢迎留言。

最近来留言提问的朋友越来越多,非常感谢大家捧场。不过现在已经多到我有点处理不过来的地步了,而且WP的留言嵌套回复功能好是好,但是套的一多就容易乱,弄的我经常漏看评论。为了能给大家更好的解决问题,关于播放的提问请到NMM论坛回帖提问,这里的评论关闭,谢谢~

Changelog:

v1.1:
修改NORMAL END部分设置,减小资源消耗,支持外挂字幕(ssnake)

v1.0:
本文诞生

继续阅读基于MPC-HC的10bit播放全攻略 v1.1

QQ/TM传送文件保证完整性的方法

对于经常用QQ/TM传文件的同学来说,应该没少碰到文件传输出错的情况。大部分的时候,传输出错会发生在因网络不稳定而频繁断线、续传的情况下。所以为了保证尽量不出错,所以还是来稍微了解一下QQ/TM的续传机制。

相信不少同学碰到过再次接收相同文件的时候无法续传的现象,想要续传是有一定条件的。那就是,传输是发送方主动断开的,如果是因为掉线、接收方重启或者其他种种情况发生的断开,那么很大几率无法进行续传。

此时想要恢复续传可以参照如下的方法:

1、将已经传送一部分的.tmp文件改一个其他名字
2、让发送方传送该文件,发送个几K之后,让发送方主动断开
3、删除刚刚接收到的tmp文件,并把之前的tmp文件改名为和刚刚删掉的tmp一样
4、再次让发送方传送,此时就可以续传了

现在来说说如何保证传送文件的完整性。

1、将文件用rar打包
这个是最最简单的方法,rar在解压的时候会进行crc校验,一旦出错会立刻提示用户。

2、rar打包并添加恢复记录
这个就更保险一些,一旦出错之后还可以使用rr进行修复。

3、利用BT的hash功能进行校验
如果传送的是大文件并且没有用rar打包,或者rr不足以修复,就可以使用这个方法。发送方用BT客户端(如uTorrent)给文件生成一个种子,再把种子或者磁力链接发给接收方并且开始做种。接收方用BT客户端打开种子文件或磁力链接,并把文件保存到与已接收文件相同的位置。此时BT客户端会发现文件已存在,并且开始进行hash校验。因为没有tracker服务器的参与,所以接收方需要手动添加发送方的IP和端口到用户列表里。校验完毕之后,客户端会开始从发送方那里下载损坏的部分。不过此方法对于内网同学来说会比较麻烦,需要做端口映射或者打开路由器的uPnP功能。

暂时想到的方法就是这些……

=================================我是分割线=================================

下面随便聊聊,说说为啥我会写这个……

昨天大虾给我传HOTD的BDMV,总共4个分卷,每个分卷3,906,250KB。这个就是断断续续传完的,最终导致了悲剧的后果……囧。我收到全部4个分卷之后,就开始解压。没想到的是,仅仅是双击打开第一个分卷rar就报错说“不可预料的文件末端”,出错文件是分卷2。结果我一看,分卷2的文件大小是3,906,251KB……我擦咧!?头一次遇到传着传着还传大了的情况!!我感到无比惊奇啊!!

还好这rar有5%的rr,尝试修复,结果修复不能……囧

于是问大虾要了分卷2制作的种子,进行hash,结果让我无语……UT显示下载量是80%!没错是80%!!整整少了20%的内容,5%的rr根本无能为力啊!到现在我都搞不清为啥会这样,不过幸好这80%都是从头开始连续的。于是我用FreeCommander的文件拆分功能,把这个不完整的文件按照78%和22%的体积比例给拆开。之后按照上面的恢复续传的方法,让78%的文件作为tmp文件进行续传,最后解决了问题,避免了彻底重传的悲剧……囧

所以说QQ/TM对传大文件要多加小心啊

另外还有一个比较奇怪的事情,就是QQ/TM传文件的速度非常快。怎么解释呢,就是说,用它传文件的时候,速度非常明显快于其他传输方法。我和大虾的测试结果是这样:
对传:800K左右
我从大虾FTP下载:15K左右
我从大虾HTTP下载:15K左右
大虾做种我用BT下载:10K左右……

FTP和HTTP,无论我用10线还是20线,都是一样的悲剧速度……BT更悲剧,连这俩都不如。完全无法和对传的速度相比。这该怎么解释?我能做出的猜测就是TX自己有一个路由表,使用他的IM客户端进行文件传送的时候,会通过这个路由表进行优化的路由选择,达到高速。其他的原因我是想不出来了,总不会是TX做了代理服务器进行中转吧……囧。希望有知道的同学告诉我一下m(_ _)m

[更新] Chapters file time calculator v0.2.1

以前的废话:

嗯,今天花了一天的时间用C写的……
没办法我编程太废……
写这东西的初衷是为了使Chapter文件处理变得简便
BD经常是把所有的chapter连在一起,分话压的话,就要把后面几话的时间全部整体前移才行
用这个小东西就能很简单的搞定 =v=

点击下载:
Chapters file time calculator v0.2.1

注意: 输入文件必须是OGG Chapters文件.

用法:
timec <输入文件> [参数]

参数:
-?    显示本帮助
-t     时间整体前移计算 (默认)
-d    时间 x 1.001 (用于DVD Decrypter)

举例:
timec    chapters.txt
timec    chapters.txt -t -d

合法文件如下:

CHAPTER01=00:23:45.424
CHAPTER01NAME= Chapter 1
CHAPTER02=00:25:16.515
CHAPTER02NAME= Chapter 2
CHAPTER03=00:26:47.606
CHAPTER03NAME= Chapter 3
CHAPTER04=00:36:32.190
CHAPTER04NAME= Chapter 4

Changelog:

0.2.1:
调整输出编号从00开始(其实无所谓……)
修正计算后第一个章节时间可能为负数的问题 =_=

0.2:
支持章节标题保留
添加可选参数
针对DVD Decrypter抓取的章节时间不准确添加-d参数用以修正

0.1.1:
增加处理章节数量到30,应该够用了
调整输出章节文件编号从01开始

欢迎反馈问题

可能是目前为止吸奶娃BD最好的处理方式

先看蓝光原图

source

 

 

再来看处理后的720,因为这片子实在是没有1080的价值

processed 

 

处理的思路是大虾(dgwxx)想出来的
大虾我信你啊啊啊啊啊啊啊啊啊啊啊!!!!!!!!!
不过本处理方式需要大量的人肉操作,所以效率不好,眼泪很多,距离量产可能还有火星撞地球的几率,嗯~

太悲剧了,今天才刚刚发现MPC-HC支持WASAPI音频输出

啊啊啊,我太悲剧了!用了这么久居然没发现有这个功能!

MPC-HC设置中输出项里,右下的DirectShow音频里选择MPC Audio Renderer,这样MPC就会使用WASAPI独占输出了。这样就避免了Win7那个共享模式采样率带来的重采样问题了呀!

而且我更加悲剧的发现,从r1297开始就添加了这个功能了。我靠我究竟是在干什么啊,这么久都没注意到。

T T

Haali Matroska Splitter 19.12.2009

Changes in Haali Matroska Splitter 19.12.2009:
• New Features:
– Added a 64-bit version
– A shell extension was removed from the splitter. This will be available seprately at a later date.
– Added truehd and mlp support for Matroska files and transpor streams
• Fixed items:
– Fixed lpcm in transport streams support

您终于更新了,真是不容易,距上一版本隔了将近一年啊……

http://haali.su/mkv/MatroskaSplitter.exe