我的域名的主机记录是自己通过Web管理的，原先的主机记录我只修改了www一项到虚拟空间，这样就应该可以通过www.phyz.net来访问网站了，我没有修改缺省主机记录(phyz.net), 可是今天无意发现，通过Opera 7.1访问www.phyz.net却不行，而我一直用IE所以没有发现。由于怀疑是Opera将www.phyz.net解析到phyz.net了，我就将缺省主机(@)记录也改到www.phyz.net的地址，过了域名解析期后，再用Opera访问发现问题已经解决。
看起来象是Opera错把主机记录解析到缺省主机记录了，可是仔细一想就不对了，应用程序只是调用socket接口访问网络，象名字解析这类的事情应该是操作系统去做的，那么IE和Opera在名字解析上应该表现一致，可为什么IE可以正常访问，而Opera就不行呢？实在是想不明白，网络上也没有找到答案 :(
尽管Opera也已经发展到7.1版本了，可是浏览这个网站还是和IE看起来有巨大差异，字体变得很小，我试着改了一下网页，发现Opera正常后，IE 就不正常了（太大），看来在CSS的实现上两个浏览器还是不兼容，我只能选择IE！不知Netscape有没有这方面的问题，我还没有看过.
2003/09/18
2003/09/13
PPPoE的MTU
我上网是通过PPPoE(PPP over Ethernet)，好像现在网通的局域网接入和电信的ADSL大部分用的这个协议，既然是over Ethernet，一定会做协议封装，那么MTU(最大传输单元)应该达不到1500，在网上看到这可能会导致部分网络应用不正常，我于是在我的机器上实 测了一把，在dos窗口下使用ping就可以了，用ping -f -l ### ****.***这样的格式，-f是设置不分片，-l设置包长，当包长超过MTU时，就会返回ICMP不能分片的错误。在我的机器上：
E:\>ping -f -l 1465 www.****.com
Pinging www.****.com with 1465 bytes of data:
Packet needs to be fragmented but DF set.
而使用1464包长是可以的。
E:\>ping -f -l 1464 www.****.com
Pinging www.****.com with 1464 bytes of data:
Reply from ###.###.###.###: bytes=1464 time=16ms TTL=123
可以算出MTU等于1464+28(28等于ping包的头部，一个IP加一个ICMP头)=1492!
然后只要在注册表里修改这个接口的MTU就可以了。
一个有趣的实验是，使用同样的方法，但是目标地址换成自己的IP地址或是127.0.0.1得到的是不同的结果1472，可见在这里环回接口的MTU仍然是1500，和PPPoE的MTU并不相等！
E:\>ping -f -l 1465 www.****.com
Pinging www.****.com with 1465 bytes of data:
Packet needs to be fragmented but DF set.
而使用1464包长是可以的。
E:\>ping -f -l 1464 www.****.com
Pinging www.****.com with 1464 bytes of data:
Reply from ###.###.###.###: bytes=1464 time=16ms TTL=123
可以算出MTU等于1464+28(28等于ping包的头部，一个IP加一个ICMP头)=1492!
然后只要在注册表里修改这个接口的MTU就可以了。
一个有趣的实验是，使用同样的方法，但是目标地址换成自己的IP地址或是127.0.0.1得到的是不同的结果1472，可见在这里环回接口的MTU仍然是1500，和PPPoE的MTU并不相等！
2003/09/11
mp3/mp3pro/wma
因为这个空间的文件大小限制，这里不能再像以前一样放128kbps的mp3了，因为一首128k的mp3大概要4～5M :(
我想只能降低采样率牺牲质量来换取空间了，可选的压缩格式有mp3,mp3pro和wma，以前并没有仔细研究过哪种格式适合更高的压缩率，只好拿现成的mp3做试验了。
经典的mp3自然是最流行的，在没有空间限制的时候，我会毫不犹豫选择mp3/128kbps，因为mp3格式在128kbps以上已经可以提供非常好的 音频质量，并且加上mp3的广泛流行，没有什么需要选择的。可惜，到了64kbps以下，mp3不再是最佳的选择了，因为经典的mp3压缩算法在 64kbps压缩下变的惨不忍'听'，音质损失非常严重。虽然我的耳朵分辨率不高，还是毫不费力能分辨出64kbps和128kbps mp3的区别。
接着我试了被微软吹的上了天的Windows Media 8 Encoder，说实话，由于对微软的一贯印象很差，没有对这个编码器报多大的幻想，不过在CoolEditPro压缩完游鸿明的《下沙》之后，我被惊呆 了，wma的表现比前面的mp3高了一个档次，甚至给我感觉不是在一个采样率下的比较。我赶忙检查了设置，没有错误，都是在64kbps下的压缩，文件大 小也相差无几，看来微软这个巨人真不可小视。不过64kbps的wma比128kbps的mp3差距还是明显的。而且有一个显著的问题是很不稳定，在某一 段听起来好像效果非常好，下一段却又明显质量下降。看来微软的这个编码器还有些问题，不过在64kbps这个采样率下，已经很让我惊喜了（怪不得现在很多 mp3播放器都支持wma, 如果没有下面的mp3pro，我想我恐怕会用微软的这个编码器了）。
最后，轮到mp3pro了，虽然网上对这个新的压缩算法评价不错，但此前我从未用过这个编码器，毕竟不够流行。在大多数软件都还不支持mp3pro格式回 放（包括winamp）的时候，CoolEditPro竟然已经支持多种采样率的mp3pro编码（果然够专业），实在让我惊喜。在同样用64kbps压 缩了《下沙》之后回放，这次是彻底的惊喜。在用mp3pro的专用播放器THOMSON mp3Pro audio player播放这首歌时，我已经基本听不出它与128kbps的mp3的区别了,真的是非常棒（也可能是我的耳朵不够好，不过明显要比wma好了)。
哈哈，这样好了，以后我会用mp3pro做录音的压缩，遗憾的是mp3pro不够流行，普通的mp3播放器（如winamp）在播放mp3pro文件，只能象mp3一样来播放，而忽略了所有mp3pro的细节，音质大打折扣，所以回放mp3pro文件，一定要下载这个mp3pro专用播放器，当然用普通的mp3播放器也是可以回放mp3pro文件，只是音质不好。
我想只能降低采样率牺牲质量来换取空间了，可选的压缩格式有mp3,mp3pro和wma，以前并没有仔细研究过哪种格式适合更高的压缩率，只好拿现成的mp3做试验了。
经典的mp3自然是最流行的，在没有空间限制的时候，我会毫不犹豫选择mp3/128kbps，因为mp3格式在128kbps以上已经可以提供非常好的 音频质量，并且加上mp3的广泛流行，没有什么需要选择的。可惜，到了64kbps以下，mp3不再是最佳的选择了，因为经典的mp3压缩算法在 64kbps压缩下变的惨不忍'听'，音质损失非常严重。虽然我的耳朵分辨率不高，还是毫不费力能分辨出64kbps和128kbps mp3的区别。
接着我试了被微软吹的上了天的Windows Media 8 Encoder，说实话，由于对微软的一贯印象很差，没有对这个编码器报多大的幻想，不过在CoolEditPro压缩完游鸿明的《下沙》之后，我被惊呆 了，wma的表现比前面的mp3高了一个档次，甚至给我感觉不是在一个采样率下的比较。我赶忙检查了设置，没有错误，都是在64kbps下的压缩，文件大 小也相差无几，看来微软这个巨人真不可小视。不过64kbps的wma比128kbps的mp3差距还是明显的。而且有一个显著的问题是很不稳定，在某一 段听起来好像效果非常好，下一段却又明显质量下降。看来微软的这个编码器还有些问题，不过在64kbps这个采样率下，已经很让我惊喜了（怪不得现在很多 mp3播放器都支持wma, 如果没有下面的mp3pro，我想我恐怕会用微软的这个编码器了）。
最后，轮到mp3pro了，虽然网上对这个新的压缩算法评价不错，但此前我从未用过这个编码器，毕竟不够流行。在大多数软件都还不支持mp3pro格式回 放（包括winamp）的时候，CoolEditPro竟然已经支持多种采样率的mp3pro编码（果然够专业），实在让我惊喜。在同样用64kbps压 缩了《下沙》之后回放，这次是彻底的惊喜。在用mp3pro的专用播放器THOMSON mp3Pro audio player播放这首歌时，我已经基本听不出它与128kbps的mp3的区别了,真的是非常棒（也可能是我的耳朵不够好，不过明显要比wma好了)。
哈哈，这样好了，以后我会用mp3pro做录音的压缩，遗憾的是mp3pro不够流行，普通的mp3播放器（如winamp）在播放mp3pro文件，只能象mp3一样来播放，而忽略了所有mp3pro的细节，音质大打折扣，所以回放mp3pro文件，一定要下载这个mp3pro专用播放器，当然用普通的mp3播放器也是可以回放mp3pro文件，只是音质不好。
2003/09/07
订阅：
博文 (Atom)
