星期三, 七月 19, 2006

关于不同Lame参数对音质的影响

今天看了一贴,说"重组VBR参数 最接近CD音质的MP3-绝对超过320K" 。贴的地址见下:
http://www.besgold.com/bbs/viewthread.php?tid=30442&extra=page%3D1

内容大概为:

今天闲来无事就随便玩弄下MP3参数设置 大有发现这是今天压MP3的参数VBR的~添加了红色部分的参数 LAME版本3.98A
-b 32 -m j -h -V 0 -B 320 -q 0 --noath -k --noshort --strictly-enforce-ISO j:联合立体声[原来的理解有所误差 认为立体声没有砍bit音质就会比砍bit的联合立体音质好经过频谱测过在VBR模式下联合立体声体积更小但音质却更好]noath:禁用ATH(滤波的一种),论坛用的 各位应该比较熟悉k:禁用除了ATH外所有其他滤波noshort:所有的帧数都用长块压制strictly-enforce-ISO:所有帧都使用ISO规则 每个帧的压制都遵守7680bit大小限制


于是本人也很想测试下—————————————————————————————————————

所有测试软件为:WaveSpectra 1.31
测试曲目为:WAV格式的《恰似你的温柔》——演唱者为蔡琴
测试目标格式为:MP3-1(-b 320 -q 3 --noath -k),MP3-2(-b 32 -m j -h -V 0 -B 320 -q 0 --noath -k --noshort --strictly-enforce-ISO ),MP3-3(--preset insance)附加一个AAC(-q=500)
编码软件为:Lame 0.98a6 和FAAC1.24.1

以下为测试的对比图:

MP3-1

MP3-2


由上面的图片可见,320kbps的MP3已经相当接近音源了
,尤其在高音方面相比以前(Lame出现之前)的MP3真的好太多了,可以说基本上听不出区别,这很大程度上要归功于Lame的出色算法 ^_^


来一张特别的,是MP3-1 与MP3-2 的频谱比较图:




至于MP3-1 与MP3-2 从频谱的比较可见,基本上是一致的,在音质上应该不会有差别!!它们的文件大小依次为10.004MB 和9.597MB ,大小相关也不大。由此可见,MP3-2 已经失去了VBR的优势(文件体积小)!!而且,VBR(MP3-2) 感觉给上始终存在着风险——因为存在着这个可能,就是VBR(\nMP3-2) 在其它类型的音乐上,是不是也能表现得如此的好呢?所以,既然在文件大小方面没有优势,还是建议用MP3-1 的参数!!

下面这张是官方的最高音质参数(-preset insance):



正如官方的介绍,对20k以上的高频是毫不留情地砍掉!!可能正因为多了这些Bitrates,20k以下的频谱真的相当漂亮!但少了的高频,会不会对音质有影响呢?我在网上经常听说MP3的高频比较模糊,可能正是这个原因。如果真的要听出这种区别,设备的级数是要高点,但Lame的设计初衷并不是为了高级别的用户群,毕竟MP3始终是有损音频格式!!所以Lame的这种参数设计是很有道理的——以高频换中音和低音,而且Lame的这种参数一直都没有太多人攻击,看来是合理的,因为Lame 给人的感觉就是严谨!!
P.S
我想,对于极少的某些注重高频的音乐是有一定的影响的。

再来看一下AAC:




真的相当漂亮,而且文件大小为8.729MB,相当有优势了!!


再看一下自己附加的一个图:AAC(q=220)




也相当漂亮,已经相当接近音源了,文件大小只有6.321MB ^_^

备注:以上图片里的曲线,WAV代表音源,007代表MP3-1, vbr代表MP3-2,AAC500代表AAC,AAC220代表AAC220.

星期四, 七月 06, 2006

介绍Python编程相关思想——动态函数重载(Dynamic Function Overloading)

All Things Pythonic
Dynamic Function Overloading
by Guido van Rossum
April 7, 2006
 
Summary
I've checked an implementation of dynamic function overloading into Python's subversion sandbox.

I'm going to stick to the term "(dynamically, or run-time) overloaded functions" for now, despite criticism of this term; the alternatives "generic functions", "multi-methods" and "dispatch" have been (rightly) criticized as well.

A slightly optimized implementation is here: http://svn.python.org/view/sandbox/trunk/overload/

Phillip Eby has suggested that my implementation is too slow; but I recommend that you run test_overloading.py and see for yourself. (This requires the Python 2.5a1 release that was just released from python.org.)

Phillip also suggested that I use issubclass() instead of relying on the MRO (method resolution order); he believes the MRO approach can cause false precision. I'm not sure I believe that, since for single dispatch my approach actually matches the class method lookup approach exactly.

There are tons of additional features or potential requirements. For example, should there be a mechanism to invoke the "next" applicable method? But the algorithm doesn't clearly produce a next method. Also, in the case of ambiguity, should an exception be raised or the default method be invoked? (Or perhaps the "next" method, if we can agree on what it is?)

In terms of optimization, I believe that a little bit of code generation could make overloaded functions nearly as fast as hand-coded functions; see 'accelerated' in test_overloading.py.

And no, this isn't for Python 2.5; it's a highly contagious but also highly controversial thing that should be tried out in Python 3000 (or perhaps as a 3rd party add-on for 2.5) first.

I totally forgot that I blogged about this earlier, over a year ago. My implementation then was pathetic compared to today's! Phillip's ideas have helped a lot.

My hope is to eventually drive PyProtocols out of the market. Phillip should be so proud of me. :-)
 
 
 
译:

Python编程思想

介绍Python编程相关思想
动态函数重载(Dynamic Function Overloading)

我已经向Python的subversion沙箱里提交了一个新的动态函数重载的实现。
尽管"(动态或运行时)重载函数[(dynamically, or run-time) overloaded functions]"这一术语受到各方批评,我还是要继续讲讲它。"(动态或运行时)重载函数"又可称为泛型函数(generic functions)、多重方法(multi-methods)或分派(dispatch),这些术语也都受到了批评。
大家可以在http://svn.python.org/view/sandbox/trunk/overload/上看到一个稍微优化过的实现。Phillip Eby曾说我的实现速度太慢,不过,我建议你们运行一下test_overloading.py,看看你们的情况怎么样。(这需要Python 2.5a 1版本,python.org刚刚发布了该版本。)
Phillip还建议我使用issubclass(),而不要依赖方法解析次序(Method Resolution Order,简称MRO)。他认为,MRO方法会导致虚假的准确性。我不知道是否会这样,因为对于单一派遣(single dispatch)而言,我的方法确实与类方法查找完全匹配。当然,这需要很多附加功能或潜在要求。例如,是否存在调用"next" 可用方法的机制?但是,算法没有清楚地生成下一个方法。另外,如果存在歧义,是否应该抛出异常或者调用缺省方法(或"next"方法,如果我们能够对它的定义达成一致的话)?
对于优化,我相信代码生成(code generation)可以让重载的函数和手写函数运行得一样快。请参见test_overloading.py中的accelerated。
这并不适用Python2.5。这是一个颇具争议的话题,所以应该到Python3000才来试验(也许可以作为Python2.5的第三方附加品)。
大约在一年前我曾经写过相关话题的blog,但是我却忘记有这么一回事了。与今天的情况相比,那时候的实现显得暗淡无光。看来,Plillip的提议还是帮了很大忙。
我希望最终将PyProtocols挤出市场。Plillip应该为我感到骄傲。

(原文链接网址:http://www.artima.com/weblogs/viewpost.jsp?thread=155514;Guido van Rossum的英文blog网址: http://www.artima.com/weblogs/index.jsp?blogger=guido

(翻译转自:http://blog.csdn.net/gvanrossum/category/217090.aspx

[转]Python 3000――配接(Adaptation) 还是泛型函数(Generic Functions)?

All Things Pythonic
Python 3000 - Adaptation or Generic Functions?
by Guido van Rossum
April 5, 2006
Summary
We've started discussing Python 3000 for real. There's a new mailing list and a branch. The first point of order is about process; a slew of meta-PEPs are being written (and the goal is to avoid a repeat of Perl 6 :-). But I'm blogging about a feature proposal that evolved dramatically over the past days.


Alex Martelli has been arguing for adaptation since the dawn of time; and at various times he's chided me for not seeing the light. Well am I ever grateful for dragging my feet!

Adaptation

Let me first briefly describe adaptation, reduced to its simplest form. The motivation comes from a common situation where an object wrapper is required (aptly named the Adapter Pattern). PEP 246 proposes a built-in function adapt(X, P) where X is any object and P a Protocol. We intentionally don't define what a protocol is; all we care about that it can be represented by an object. The call adapt(X, P) returns an object constructed from X that satisfies P, or raises an exception if it can't. It uses a global registry which maps types and protocols to adapter functions; we can write this as a dict R = {(T, P): A, ...}. Then, adapt(X, P) computes the adapter A = R[type(X), P] and then returns A(X). There is a registration function register(T, P, A) which simply sets R[T, P] = A. Read Alex's post for a gentler explanation (and lots of things I left out).

As soon as Alex had posted this version of how adaptation works, several people (including myself) independently realized that the global registry (which has always been a sore point to some) is a red herring; the registry could just as well be separated out per protocol! So now we make adapt() and register() methods on the protocol: instead of adapt(X, P) we write P.adapt(X) and instead of register(T, P, A) we write P.register(T, A). The signature of A is unchanged. I call this "second-generation adaptation".

The nice thing about this is that you no longer have a fixed global implementation of exactly what register() and adapt() do. Alex mentions a whole slew of issues he's ignoring but that would need to be addressed for a real-life implementation, such as how to handle adaptation for an object where its type hasn't been registered but some base type has been registered; or the notion of inheritance between protocols (useful when you equate protocols with interfaces, as in Zope and Twisted); or automatic detection of the where an object already implements a protocol/interface (again useful in Zope and Twisted). Several of those extensions make lookup performance an issue, and there are different ways to address that. By having multiple protocol implementations (each implementing the same adapt() and register() APIs) each framework can have its own notion of how adaptation works for its own protocols, without having to deal with a fixed global implementation of adaptation that may or may not do the best thing for a particular framework.

Generic Functions

But then Ian Bicking posted a competing idea: instead of adaptation, why don't we use generic functions? In his and Phillip Eby's view these are more powerful than adapters, yet in some sense equivalent. Let me briefly describe generic functions to set the stage.

A generic function, G, is a callable that behaves like a function (taking arguments and returning a value) but whose implementation is extensible and can be spread across different modules. TG contains a registry of implementations which is indexed by a tuple of the combined types of the arguments. Suppose we want G to be callable with two arguments, then the registry would map type pairs to implementation functions. We'd write G.register((T1, T2), F) to indicate that F(X1, X2) is a suitable implementation for G(X1, X2) when type(X1)==T1 and type(X2)==T2. The simplest implementation would just map the arguments to their types (or better, classes), convert to a tuple, and use that as a key in the registry to find the implementation function. If that key is not found, a default implementation is invoked; this is provided when G is first defined and can either provide some fallback action or raise an exception.

A useful implementation of generic functions must also support looking for matches on the base types of the argument types. This is where things get hairy, at least when you have multiple arguments. For example, if you have a solution that is an exact match on the first argument and a base type match on the second, and another that is a base type match on the first argument an exact match on the second; which do you prefer? Phillip Eby's implementation, RuleDispatch (part of PEAK) refuses to guess; if there isn't one dominant solution (whatever that means) it raises an exception. You can always cut the tie by registering a more specific signature.

C++ users will recognize generic functions as a run-time implementation of the strategy used by the C++ compiler to resolve function overloading. Fortunately we're not bound by backwards compatibility with C to repeat C++'s mistakes (which, for example, can cause a float to be preferred over a bool). Lisp or Dylan users (are there any left? :-) and PyPy developers will recognize them as multi-methods.

In order to contrast and compare the two ideas, I posted a very simple version of adaptation and generic functions, applied to the idea of reimplementing the built-in iter() function. I used descriptors for registration, making the signatures slightly different from what I showed above, but the essence is the same.

The Lightbulb Went Off

Now we're ready for the Aha! moment (already implicit in Ian's and Phillip's position), brought home by an altenative version of the Protocol independently developed by Tim Hochberg: P.adapt(X) is just a verbose way of spelling a generic function call G(X)!

Interestingly, it took Alex a little time to like this -- he was thinking of adaptation as more powerful because it can return an object implementing several methods, while doing the same thing with generic functions would required a separate generic function for each method. But of course we can write a generic factory function, which returns an object with multiple methods, just like adapt() can; and the generic function approach wins in the (common) case where we want to adapt to a "point protocol" -- an interface with just one method, which we immediately call in order to obtain the desired result. When using adaptation, this would require each adapter to use a helper class with a single method that does the desired operation; when using a generic function, the generic function can just do the operation. And we haven't even used generic function dispatch on multiple arguments!

I'm not sure where this will eventually lead; but I've already killed PEP 246 (adaptation) and PEP 245 (interfaces) in anticipation of a more "generic" proposal.

Acknowledgements

  • Aahz, for bringing Alex's post to my attention
  • Google, for getting Alex and me together on the same campus so we could have face time
译:

我们开始真正地讨论Python3000了。这里有一个新的邮件列表和一个版本分支。首要的问题是关于流程的。Python 增强建议书(Python Enhancement Proposal,简称PEP)的很多新格式正在制定,目的是为了避免重蹈Perl 6的覆辙:-)。这篇blog所讨论的东西在过去一段时间里已经发生了很大的变化。

自盘古开天地之日起,Alex Martelli就一直是配接的忠实拥护者。他经常埋怨我对配接的光芒视而不见。现在,我为自己当时的不开窍而感到庆幸。

我先用最简单的形式来介绍一下配接吧。当需要用到对象包装器(object wrapper)[配接器模式(Adapter Pattern)或许更贴切]时,我突然萌发了这个想法。PEP246打算提供一个内置的函数adapt(X, P), X可以是任何对象,而P也可以是任何Protocol。我们故意不对protocol进行定义,只要它可以通过对象表现出来就可以。调用adapt(X, P)返回一个由X构建并满足P的对象,如果创建对象失败,则抛出一个异常。它使用全局注册表(global registry)为配接器功能提供了类型和protocol之间的映射关系。我们可以写为dict R = {(T, P): A, ...}。然后,adapt(X, P) 计算出adapter A = R[type(X), P],并返回A(X)。 还有一个注册函数register(T, P, A),它简单地设置 R[T, P] = A。请参见Alex更为精彩的解释,他补充了很多我遗漏掉的东西。

当Alex提出他对配接工作原理的这一看法,好几个人(包括我自己在内)都意识到全局注册表(对一些人来说,它永远是一个伤痛)是没有必要的。每个protocol都可以有自己的注册表(registry)。所以,现在我们在protocol上使用adapt()和register()方法。我们使用P.adapt(X)而非adapt(X, P),使用P.register(T, A)而非register(T, P, A)。A的签名(signature)保持不变。我称之为第二代配接(second-generation adaptation)。

对于register()和adapt()到底有什么用,你们再也不用局限于一种固定的全局实现,这是一个好消息。Alex提到了很多他忽略的问题,但是如果要真正实现,这些问题需要得以解决。例如,如何处理对象类型未被注册而一些基本类型已被注册的配接,protocol之间的继承是如何定义的(当你把protocol和接口看得同等重要时会很有用,就像Zope和Twisted一样),对象已实现protocol/接口时的自动检测(这在Zope和Twisted中有用)。这些扩展(extension)使得查找性能(lookup performance)成为一个问题,我们可以通过几种不同的方法来解决。通过多重协议实现(multiple protocol implementations)(每次都实现adapt()和register() APIs),每个框架(framework)都对配接如何为其自身拥有的protocol服务有自己的主张,而没必要使用一个固定的全局实现。对于一个特定的框架而言,配接的全局实现可能达到最佳效果,但也未必就是最好的选择。

Ian Bicking提出了一个对立的观点:我们为什么不使用泛型函数而非配接呢?他和Phillip Eby都认为泛型函数具有的功能比配接器更强大,至少可以与之抗衡。现在我就来简要说一下泛型函数。

一个泛型函数G,可以被调用,这种行为类似一个普通函数(取参数并返回一个值),但其实现是可扩展的(extensible),并可以在不同的模块中进行定义。TG包含一个由复合类型参数的元组索引的注册表实现。假设我们想让具有两个参数的G可调用,那么注册表将会把type pairs映射到实现的函数中。我们可以使用G.register((T1, T2), F) 来显示地定义,当type(X1)==T1、type(X2)==T2时,F(X1, X2)是G(X1, X2)的合适的实现。 最简单的实现就是把参数映射到它们的类型(类或许更好),转换为元组,并利用它作为注册表的键值来找到实现函数。如果没有找到健值,就调用缺省实现,前提是预先定义G,并提供一些恢复措施或抛出一个异常。

一个有用的泛型函数实现也必须支持在参数类型的基本类型上查找匹配。这就是使事情变得复杂的地方,特别是当你有多个参数时。例如,你有一个实现方案,它与第一个参数完全匹配,基本类型与第二个参数匹配;另一个实现方案是,它与第二个参数完全匹配,基本类型与第一个参数匹配。这种情况下,你会选择哪一种?Phillip Eby的实现、RuleDispatch (part of PEAK) 拒绝做出猜测; 如果没有占优势的实现方案(不管它是什么意思),都会抛出异常。你可以通过注册一个更加具体的签名来彻底解决问题。

C++用户会认为泛型函数是一个C++编译器用来解决函数重载问题的策略的运行时实现。幸运的是,我们不需要与C向后兼容,从而避免了重蹈C++的错误(如,导致浮点类型的优先级高于布尔类型。)。Lisp或 Dylan用户(不知是否还存在:-),以及PyPy 开发者会认为它们是多重方法(multi-methods)。

为了对比上述两种观点,我提出了一个关于配接和泛型函数的一个简单版本,通过这一版本来再现内置iter()函数的重复实现。我在注册表中使用了描述符,这使得签名与我上面所述有一些轻微的差别,但实质是一样的。

胜负分晓了
现在我们已经为庆祝时刻做好准备了。Tim Hochberg独立开发的一个可以替代的Protocol版本给我们带来了这一欢乐时刻。P.adapt(X)只是泛型函数G(x) 调用的另外一种冗长形式罢了。

有趣的是,Alex费了一些周折才开始喜欢上它。他过去一直认为配接的功能更强大,因为配接可以返回实现多个方法的对象,而泛型函数要实现同样的功能则要求每个方法都有一个单独的泛型函数。当然,我们可以使用泛型工厂函数(generic factory function),它可以像adapt()一样返回带有多个方法的对象。当我们想要适应"point protocol"时,泛型工厂函数也可以起到作用。point protocol是一个只有一个方法的接口,可以马上调用,以获得想要的结果。在使用配接时,这可能要求每个配接器使用一种单一方法的helper类,helper类来完成预期的运行。在使用泛型函数时,泛型函数则可以完成运行。我们还没有在多个参数上使用过泛型函数分派。

我不知道这样是否会成功,但是还没有想到更加通用的方案前,我已kill掉了PEP 246 (配接) 和PEP 245 (接口) 。

(原文链接网址:http://www.artima.com/weblogs/viewpost.jsp?thread=155123;Guido van Rossum的英文blog网址: http://www.artima.com/weblogs/index.jsp?blogger=guido



[转自] http://tb.blog.csdn.net/TrackBack.aspx?PostId=869173


星期二, 七月 04, 2006

从头认识陈慧娴之《娴情》

转帖:从头认识陈慧娴之《娴情》
 
       1988年1月,宝丽金为陈慧娴推出了她的个人第5张粤语专辑《娴情》。当时的陈慧娴已随着"逝去的诺言"、"花店"、"跳舞街"等作品的传唱取得了一定的知名度。但是由于此前一直是一种单纯的邻家少女形象,所以歌迷仍主要集中在学生群体中,她在香港歌坛的位置也仍停留在二线上。在上一张专辑《变变变》销量及口碑都不尽如人意的情况下,她在时隔一年之后才慎重地完成了这张日后证明相当成功的转型之作。在这张专辑中,陈慧娴的角色已经不再只是刚出道时那个由制作人给她讲述故事、让她自己来诠释感觉的小女生;而是首次和区丁玉一起担纲整张专辑的制作,并独立提出封套的概念。在当时香港乐坛翻唱风大行其道的环境下,专辑里的十首歌曲竟全部是舶来品的改编,但也同时凸现了区丁玉和陈慧娴两位制作人在选曲和编制上精心。而封套的创意和设计,也让陈慧娴"帽子歌后"的形象深入人心。

  专辑以两首劲歌"不住怨妇街"和"不羁恋人"拉开序幕。同此前她的快歌如"跳舞街"、"反叛"、"变变变"相比,这两首歌在内容上明显地成人化。但有别于同期梅艳芳善用低沉的声线表现妖艳狂放的劲歌风格,陈慧娴扬长避短地采用偏轻快跳跃的方式来进行演绎,突出靓丽的音色和清晰的吐字,更别有一番风情。尤其在"不住怨妇街"中,她采用一些比较搞怪的发音方式,起到一种转型中承上启下的作用。接下来的"不羁恋人"则要中规中矩一些,也就此完全掀开了转型后成熟风格的序幕。

  两首劲歌之后,紧接着则是连续四首中板情歌:"渺茫的爱"、"沉寂午夜"、"一对寂寞的心"和"傻女"。其中最为知名也最有意义的莫过于"傻女"了,它可以说是陈氏情歌都市淑女风格的奠基之作。林振强的填词相当精彩,以穿旧情人留下的毛衣为切入点刻画出一位痴心傻女感人至深的形象。这与林夕后来为王菲所填的"暧昧"("你的衣裳今天我在穿")有些异曲同工之妙,只是用了更多的笔墨来集中渲染这种夜半无人私语时的氛围,至今仍如教科书一般为许多填词人所津津乐道。而卢东尼几乎只用上了钢琴,就衬着陈慧娴的歌声将悲伤的感觉逼入人心。这首"傻女"是当年最热门的歌曲之一,并顺利地连续入围年终的十大中文金曲和十大劲歌金曲,成为陈慧娴的一首传世经典和标志之作。

  "一对寂寞的心"是另一首值得一提的佳作。这是陈慧娴和张学友在音乐上第一次正式的合作。当时的陈慧娴论资历和人气都在张学友之上;加上张学友因酗酒闹事,正处在事业的最低谷。身为张学友义妹的陈慧娴不仅去医院探访了张学友,而且答应他伤愈后一起合作一首歌,于是便有了这首对唱作品的诞生。这是一首很清新的都市对唱情歌,描述一对寂寞中人近情情怯的心理。当时尚非天王天后的张学友和陈慧娴已从这段时期开始逐渐显露锋芒,这首歌也成为两人多次合作中难得的"青春期作品"。虽初时感觉有些青涩,细细咀嚼竟也回味无穷。

  相形之下,"渺茫的爱"和"沉寂午夜"就显得相当平稳。但前者的编曲(卢东尼)比较出色,尤其是临近结束时给人一种痛彻心扉无语凝噎的感受;后者的曲式相对沉闷一些,但陈慧娴的演绎和杜自持的编曲仍保证了一定的可听性。填词人是香港商台的著名DJ陈海琪,也是专辑中的一个亮点。

  "BadGirl"和"MoneyCan\'tBuyLove"是接下来相连的两首快歌,风格又回到《反叛》时期的快歌路线上,应当是稳定一些旧歌迷的需要。徐日勤的编曲照例说不上前卫和突破,但却很有时代的特色;而陈慧娴充满少女风情的演绎显得驾轻就熟,表现不过不失。

  专辑以两首具有一定意义的"夜半歌声"和"岁月流声"结束。"夜半歌声"描述一个痛失母爱、街头卖唱的孤儿的伶仃无助,就象是"火柴天堂"的男孩版。当时的香港歌坛不时会有一些关注与思考社会问题的佳作问世,这首歌也是其中之一。填词人小美是当时新晋的词人。词锋与此前的"有谁共鸣"相似,颇有一些自己独辟蹊径的看法和见解。"真想知道可有公平宇宙",仍不时回旋耳畔,迟迟不肯散去。而"岁月流声"则明显轻快许多,典型的竹内玛利亚式的偏乡谣的流行曲风。杜自持包办了这两首风格迥异的作品的编曲,和陈慧娴的演绎相得益彰,可见二人的默契与功力。陈少琪的填词则勾勒了一幅女主人公NATALIE从点歌的邻家少女实现梦想成长为放歌的电台DJ的画面。歌曲畅快隽永又回味悠长,似乎从一个侧面反映了歌手的成长史,有种自传的感觉。以此作为结束曲,感觉相当的精心和完美。

  这张专辑一经推出,迅速赢得了很好的口碑和销量。成功转型为带有少女情怀的都市淑女形象以及专辑销量逼近三白金的好成绩,都为陈慧娴当年获得叱咤乐坛女歌手银奖并一举成为香港歌坛天后增添了许多砝码。这是一张象征着陈慧娴跨入香港一线女歌手的作品。当时22岁的陈慧娴第一次担任制作人就取得了值得称赞的佳绩,并在香港歌坛初步形成了梅陈林叶四大天后的鼎足之势。



曲目:
1.不住怨妇街
2.不羁恋人
3.渺茫的爱
4.沉寂午夜
5.一对寂寞的心 (陈慧娴、张学友合唱)
6.傻女
7.Bad Girl
8.Money Can't Buy Love
9.夜半歌声
10.岁月流声

[旧碟重温]--陈慧娴《正视爱》

[转自茶馆],作者:阿永 ------------

99年由新艺宝发行的这张<正视爱>,是陈慧娴真正意义上的第一只由新唱片公司所承担制作的唱片。离上张概念大碟也有一年多的时间,<正视爱>的发行可算是另人眼前一亮。陈慧娴也罕有地位配合唱片风格而剪短了头发,尝试淡化年龄的尴尬,唱著非自己所长的电子味浓重的歌曲,整张专辑主要由方树梁作为监制,可见唱片公司也希望陈慧娴能在音乐上有所突破。专辑给人的感觉比较陌生,看不到适日陈慧娴的影子。 主打歌<正是爱><什麼都想要>稳守一二线,仿佛逼不及待地要告诉别人陈慧娴的转变。<正是爱>歌词很有意思,整首歌都是在阐述现代爱情观。“某两个人,只一晚热爱,下半世已是深刻的记载。”帮陈慧娴填料多年词的陈少琪,不似林夕那样填词总是煞有介事地带点玄,却非常简单易明,但又经常导出真理。这首歌编曲较为商业化,算是抓稳了潮流的脉搏,和後面的一首<正是爱>REMIX版那样,都非常适合唱K。作为主打歌之首,无疑是看准了年轻乐迷的市场,希望从中得到一定的肯定。耐何陈慧娴也不是新人,这类型的歌曲本身是可具水准,但作为陈慧娴歌路转变的试金石,似乎还缺乏一点审时度势。 <什麼都想要>乃陈慧娴多年来的仅有的一两首K歌。由梁芷珊填词,吴国劲作曲,组合是比较新鲜,歌曲本身也颇为动听。吴国劲虽然认识陈慧娴比较旧,但他更多的是以SAMMI的合作,而且两人也更有默契。<什麼都想要>曲风也算是新专辑的一个特色,只嫌歌曲过场部份过於激情,而陈慧娴的演绎好像给人有声嘶力竭的感觉。也许是为了适应歌曲风格,也许是多年来声线磨损所留下的痕迹。梁芷珊在专辑中共填了两首词,包括这首<什麼都想要>和<灵犀>。歌词讲述失恋後的空虚无阻以及孤单寂寞的心境,所表达的内容与歌曲名称刚好相反,变得“什麼都不紧要”。总的来说,两首主打歌都较有新鲜感。作出了一定程度的风格和歌路的转变,可能如果陈慧娴当年是以新人的姿态出现的话,我对两首歌的评价会高些。 <山手线>本是专辑内的第一主打歌,但因在专辑筹备当中因封面概念被盗,原本由张姓男友构思的日本风情为主题的封面被同公司的古巨基的新专辑所抢先采用,直接另歌曲变为可有可无的第三主打。虽然如此,但仍掩不住歌曲所散发的异国乡情。山手线本为日本东京最著名的一条铁路干线,歌曲直接取其名称,而前奏和结尾混入火车行驶过程的背景声音另歌曲本身增加不少分数。陈慧娴在演绎上采取接近气声的唱法,使得歌曲本身更填渲染力。一首清新怡人的小品,洋溢著外国的乡间风味,最适宜忙碌的都市人来调节一下紧张的生活节奏。 <灵犀>是描述当年陈慧娴跟张姓男友的爱情生活,非常小品。本来陈慧娴有意自己执笔填词,但最後只是写了一篇她的爱情生活体验,而再由梁芷珊根据其大意填词。心有灵犀一点通。歌词描写了那平凡之中带点工作的紧张,忙碌的工作之中带点甜蜜的温馨的感觉,活像一对新婚的小恋人。只可惜种种原因,歌词的故事意境并不能延续到现实中去。重听这首歌,仿佛是看著伊人的日记那样。而相比起国语版的<谢谢你的爱>,可能由於多次登台的演出,国语版比粤语版更受欢迎。其实陈慧娴当年应该顺著在港事业的下滑,而到内地寻求发展,而不是唱著不适合自己风格的歌曲去争取年轻乐迷的耳朵的。 <长情>风格有点另类。歌曲在编排上处理得不太理想,第二部份声部过高,而陈慧娴的演绎则有点刻意卖弄唱功。其实唱一些入流点的作品比起这些并不适合自己风格的歌曲,可能会讨好市场一些。 <他知道我知道>回归到典型的陈慧娴惨情歌歌路上,跟<问题女人>里的<我肯,我等,我害怕>有点相似。林夕的名气并没有为陈慧娴的歌曲带来优越性。稍微喜欢的只是他更早时期所填的<心满意足>和<二人时间>。这首歌的风格跟上张概念大碟部份副歌风格一样,没有太大变化。比较平庸。 <流水行云>乃香港电台<笑傲江湖>广播剧的主题曲。歌曲本身另人联想起其与谭校长合唱的<活得潇洒>,同样是<笑傲江湖>主题曲,不过後者则倚著电视剧的播放而为歌曲增添不少知名度。但其实<流水行云>则更加洒脱。歌词中人物的个性被描绘得淋漓尽致。"或有泪,但从没有憾,浪似他胸襟拥抱风和云,真的心不懂怨恨,宽敞得很".也许填词的林振强本身就是如此的一个不羁汉子。