苹果的云音乐专利申请曝光 - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Apple - 家有苹果

苹果的云音乐专利申请曝光

苹果的云音乐专利申请曝光# Apple - 家有苹果

a*y2011-05-19 07:05

1 楼

sync partial music
你可以立即开始播放，然后剩余的部分从云里开始stream过来。没有lag，没有
buffering。这个很好。
http://www.9to5mac.com/67943/apple-patent-reveals-seamless-and-

s*n2011-05-19 07:05

2 楼

" 这个很好。" ?
好啥? 这也太果果粉了 ...
In my not so humble opinion, this is a typical protective or extended or
junk claim ... which doesn't make sense in practice. My feeling is, the
idea basically is a variation of pre-caching, which is not something new.
OK. Even though Apple somehow added some novelity into this claim, the
basic assumption behind it is the communication is always on, which
apparently is not true for most people.

content/uploads/2011/05/6a0120a5580826970c01538e945867970b-800wi.jpg
invisible-to-the-user-cloud-music/

【在 a***y 的大作中提到】

: sync partial music
: 你可以立即开始播放，然后剩余的部分从云里开始stream过来。没有lag，没有
: buffering。这个很好。
: http://www.9to5mac.com/67943/apple-patent-reveals-seamless-and-

a*y2011-05-19 07:05

3 楼

我到目前为止没有见过任何一个服务使用这种pre-caching。如果你要证明这不是什么
创新，至少请举证。
所有streaming服务，我见过的用过的，基本都有buffering time
如果苹果只需要每首歌pre-cache 10秒到你的iPhone上，每首歌只占大约0.30MB per
256Kbps AAC/MP3.
这样我8000首的曲库只需要2G多就可以放下了。而且无需buffer，这种完全符合苹果一
般追求的seamless的体验，只要网速够快，用户不会体会到和完全本地播放的区别。

【在 s*********n 的大作中提到】

: " 这个很好。" ?
: 好啥? 这也太果果粉了 ...
: In my not so humble opinion, this is a typical protective or extended or
: junk claim ... which doesn't make sense in practice. My feeling is, the
: idea basically is a variation of pre-caching, which is not something new.
: OK. Even though Apple somehow added some novelity into this claim, the
: basic assumption behind it is the communication is always on, which
: apparently is not true for most people.
:
: content/uploads/2011/05/6a0120a5580826970c01538e945867970b-800wi.jpg

i*12011-05-19 07:05

4 楼

卖硬盘的最恨这种云，

【在 a***y 的大作中提到】

: 我到目前为止没有见过任何一个服务使用这种pre-caching。如果你要证明这不是什么
: 创新，至少请举证。
: 所有streaming服务，我见过的用过的，基本都有buffering time
: 如果苹果只需要每首歌pre-cache 10秒到你的iPhone上，每首歌只占大约0.30MB per
: 256Kbps AAC/MP3.
: 这样我8000首的曲库只需要2G多就可以放下了。而且无需buffer，这种完全符合苹果一
: 般追求的seamless的体验，只要网速够快，用户不会体会到和完全本地播放的区别。

s*n2011-05-19 07:05

5 楼

It is hard to think out any pre-existing implementation of it.
Otherwise, this application would be denied. Or, maybe I missed
something. Now my second guess is, maybe it is about something similar
to SVC.
When you do local sync, iTune only stores a copy of the base-layer
encoding of content on your iDevice. Later on, when you want to listen
to the music or watch the movie, additional enhanced layers of the
content will be streamed into your iDevice.
This idea is to make sure you can alway listen to or watch your
contents, even though you may not have the network always available .
The difference is, when the network is available, you can do higher-
quality contents.

【在 a***y 的大作中提到】

a*y2011-05-19 07:05

6 楼

Layer?

【在 s*********n 的大作中提到】

: It is hard to think out any pre-existing implementation of it.
: Otherwise, this application would be denied. Or, maybe I missed
: something. Now my second guess is, maybe it is about something similar
: to SVC.
: When you do local sync, iTune only stores a copy of the base-layer
: encoding of content on your iDevice. Later on, when you want to listen
: to the music or watch the movie, additional enhanced layers of the
: content will be streamed into your iDevice.
: This idea is to make sure you can alway listen to or watch your
: contents, even though you may not have the network always available .

s*n2011-05-19 07:05

7 楼

Yes .... for MP4/H.264/AVC, the video is indeed coded into more than one
layers, base layer and enhancement layers, depending on profiles. This is
called SVC, Scalable Video Coding. The receiver can decode the video into
streams of different qualities, depends on the channel condition or the
output terminals...

【在 a***y 的大作中提到】

: Layer?

a*y2011-05-19 07:05

8 楼

I see.
I think this patent is related to music instead of video streaming

【在 s*********n 的大作中提到】

: Yes .... for MP4/H.264/AVC, the video is indeed coded into more than one
: layers, base layer and enhancement layers, depending on profiles. This is
: called SVC, Scalable Video Coding. The receiver can decode the video into
: streams of different qualities, depends on the channel condition or the
: output terminals...

s*n2011-05-19 07:05

9 楼

The concept of SVC has been applied to speech coding ... not sure if
anything similar in MP3 or not ...

【在 a***y 的大作中提到】

: I see.
: I think this patent is related to music instead of video streaming

l*f2011-05-19 07:05

10 楼

早日摆脱数据线

f*52011-05-19 07:05

11 楼

好在可以把整个库放在设备上。
次在对拖拉操作没意义。

【在 s*********n 的大作中提到】

s*n2011-05-19 07:05

12 楼

depends. ... If Apple is doing like what I guess before and put the base-
layer music on local iDevice while move enhancement-layer music in the
remote servers, it is possible for iFans to do 拖拉操作..

【在 f*******5 的大作中提到】

: 好在可以把整个库放在设备上。
: 次在对拖拉操作没意义。

f*52011-05-19 07:05

13 楼

你这种方式有明显的缺点。1.大部分数据都用不上；2.每次播放都有几秒钟质量由次变
好，基本不可接受的。

【在 s*********n 的大作中提到】

: depends. ... If Apple is doing like what I guess before and put the base-
: layer music on local iDevice while move enhancement-layer music in the
: remote servers, it is possible for iFans to do 拖拉操作..

s*n2011-05-19 07:05

14 楼

I guess nothing is perfect ... Indeed I prefer to store all my stuff
locally and use the network as a backup. So far I haven't been convinced
by the benefits brought by cloud players. Maybe it is a life-style
changing excuse persuaded by these internet companies.
1.大部分数据都用不上；? What does this mean? You can always store your whole
songs online.
2.每次播放都有几秒钟质量由次变好，基本不可接受的。 Maybe it has fewer jitterings
and at least you are guaranteed to hear a whole song whatever the network
is available or not.
BTW, these two approaches don't conflict with each other. More
aggressively you can store the first few seconds of each whole song
locally too.

【在 f*******5 的大作中提到】

: 你这种方式有明显的缺点。1.大部分数据都用不上；2.每次播放都有几秒钟质量由次变
: 好，基本不可接受的。

f*52011-05-19 07:05

15 楼

1.大部分数据都用不上；? What does this mean? You can always store your whole
我是说存在设备上的数据除了开始播放点部分，大部分都用不上。比如256kbps的歌你
存个64kbps的。你说在正常播放时我是愿意直接播放网上传过得完全数据，还是接受完
90%的网上数据，再加个io读设备，再匹配时间点。。。
jitterings
apple可以加个可选项，但这对pr绝对不好。
质量和空间不可坚固。呵呵

【在 s*********n 的大作中提到】

: I guess nothing is perfect ... Indeed I prefer to store all my stuff
: locally and use the network as a backup. So far I haven't been convinced
: by the benefits brought by cloud players. Maybe it is a life-style
: changing excuse persuaded by these internet companies.
: 1.大部分数据都用不上；? What does this mean? You can always store your whole
: songs online.
: 2.每次播放都有几秒钟质量由次变好，基本不可接受的。 Maybe it has fewer jitterings
: and at least you are guaranteed to hear a whole song whatever the network
: is available or not.
: BTW, these two approaches don't conflict with each other. More

a*y2011-05-19 07:05

16 楼

agree

【在 f*******5 的大作中提到】

: 你这种方式有明显的缺点。1.大部分数据都用不上；2.每次播放都有几秒钟质量由次变
: 好，基本不可接受的。

s*n2011-05-19 07:05

17 楼

1) 我是说存在设备上的数据除了开始播放点部分，大部分都用不上。
I guess you might misunderstand the concept of layered coding and
decoding ... If 64kbps的 is stored in local iDevice and 256kbps的歌 is
stored in the cloud, then each time only the difference, 增强数据, i.e.
enhancement layers, between 64kbps的 and 256kbps的歌 will be streamed
into your iDevice.
If your iDevice couldn't promptly and correctly receive additional 增强数
据 from the cloud, it will only decode the local 64kbps的. Otherwise, it
will output the full quality with combining 增强数据 and the local 64kbps
的.
So this means, it is the opposite. 存在设备上的数据 always 用上 ... but the
数据 store in the cloud may or may not be able to be used.

whole

【在 f*******5 的大作中提到】

:
: 1.大部分数据都用不上；? What does this mean? You can always store your whole
: 我是说存在设备上的数据除了开始播放点部分，大部分都用不上。比如256kbps的歌你
: 存个64kbps的。你说在正常播放时我是愿意直接播放网上传过得完全数据，还是接受完
: 90%的网上数据，再加个io读设备，再匹配时间点。。。
: jitterings
: apple可以加个可选项，但这对pr绝对不好。
: 质量和空间不可坚固。呵呵

f*52011-05-19 07:05

18 楼

64kbps的歌往小里说假设0.5M，256kbps得5M。apple为了.5M的数据，除了保留一份完
整的文件，还得实时计算或者预先存一份4M的数据，怎么看这个设计都不靠谱。

【在 s*********n 的大作中提到】

: 1) 我是说存在设备上的数据除了开始播放点部分，大部分都用不上。
: I guess you might misunderstand the concept of layered coding and
: decoding ... If 64kbps的 is stored in local iDevice and 256kbps的歌 is
: stored in the cloud, then each time only the difference, 增强数据, i.e.
: enhancement layers, between 64kbps的 and 256kbps的歌 will be streamed
: into your iDevice.
: If your iDevice couldn't promptly and correctly receive additional 增强数
: 据 from the cloud, it will only decode the local 64kbps的. Otherwise, it
: will output the full quality with combining 增强数据 and the local 64kbps
: 的.

s*n2011-05-19 07:05

19 楼

I am pretty sure, even if you store your whole 256kbps songs in the
iCloud after it is launched, iCloud will not always stream the whole
256kbps to you when you want to listen to it. It may do transcoding and
stream 128kbps or 64kbps to your iDevice, depending on the link condition
between your iDevice and iCloud.
My point is 实时计算或者预先存一份4M的数据 is already there and always there in
any multimedia content delivery service. No additional overhead
as you said .....

【在 f*******5 的大作中提到】

: 64kbps的歌往小里说假设0.5M，256kbps得5M。apple为了.5M的数据，除了保留一份完
: 整的文件，还得实时计算或者预先存一份4M的数据，怎么看这个设计都不靠谱。

f*52011-05-19 07:05

20 楼

这个开销可以忽略的话，更符合我的point了，根本没必要存差别数据，就是传完整数
据，无论你是否降级。

【在 s*********n 的大作中提到】

: I am pretty sure, even if you store your whole 256kbps songs in the
: iCloud after it is launched, iCloud will not always stream the whole
: 256kbps to you when you want to listen to it. It may do transcoding and
: stream 128kbps or 64kbps to your iDevice, depending on the link condition
: between your iDevice and iCloud.
: My point is 实时计算或者预先存一份4M的数据 is already there and always there in
: any multimedia content delivery service. No additional overhead
: as you said .....

s*n2011-05-19 07:05

21 楼

Come on ... Look at LZ's post and ask the question again ....
But your question is legitimate. Give you a very simple example. If you
look at youTube plugin carefully, you will find it gives many resolution
options, 360p, 480p, 720p, before streaming. This means, youTube has
stored multiple resolution versions of each video in its cloud.
However, even with this, there are some imperfections of youtube stream it
can't overcome now. The delay is always there and the lowest resolution
streaming is not guaranteed . I guess you know why ...

【在 f*******5 的大作中提到】

:
: 这个开销可以忽略的话，更符合我的point了，根本没必要存差别数据，就是传完整数
: 据，无论你是否降级。

l*n2011-05-19 07:05

22 楼

还是得有网速的前提呀

【在 a***y 的大作中提到】

f*52011-05-19 07:05

23 楼

在存每首歌开头多少秒完整数据的方式和你的完整歌的低码率方式之间，我会选前者。
质量跟不上我可以怪att网速跟不上。但是网络跟的上，一开始却听出噪音来的，那就
等着挨骂了，尽管你说我支持拖拉。。

【在 s*********n 的大作中提到】

: Come on ... Look at LZ's post and ask the question again ....
: But your question is legitimate. Give you a very simple example. If you
: look at youTube plugin carefully, you will find it gives many resolution
: options, 360p, 480p, 720p, before streaming. This means, youTube has
: stored multiple resolution versions of each video in its cloud.
: However, even with this, there are some imperfections of youtube stream it
: can't overcome now. The delay is always there and the lowest resolution
: streaming is not guaranteed . I guess you know why ...

s*n2011-05-19 07:05

24 楼

" .....
BTW, these two approaches don't conflict with each other. More
aggressively you can store the first few seconds of each whole song
locally too."
在存每首歌开头多少秒完整数据的方式和你的完整歌的低码率方式之间，我会选前者 ...
these two approaches are for different issues of streaming ... indeed .
This first one is for delay, the second one is for the limitation of link
capacity .
It is unnecessary for you to prefer one to the other ...

【在 f*******5 的大作中提到】

: 在存每首歌开头多少秒完整数据的方式和你的完整歌的低码率方式之间，我会选前者。
: 质量跟不上我可以怪att网速跟不上。但是网络跟的上，一开始却听出噪音来的，那就
: 等着挨骂了，尽管你说我支持拖拉。。

f*52011-05-19 07:05

25 楼

我问你，用户一下拖到2分种得点，你怎么反应？
1）先播本地低码率数据？有噪点
2）等增强数据？有延迟，那存低码率数据的意义何在,尤其省不了多少带宽。

【在 s*********n 的大作中提到】

: " .....
: BTW, these two approaches don't conflict with each other. More
: aggressively you can store the first few seconds of each whole song
: locally too."
: 在存每首歌开头多少秒完整数据的方式和你的完整歌的低码率方式之间，我会选前者 ...
: these two approaches are for different issues of streaming ... indeed .
: This first one is for delay, the second one is for the limitation of link
: capacity .
: It is unnecessary for you to prefer one to the other ...

s*n2011-05-19 07:05

26 楼

" 在存每首歌开头多少秒完整数据的方式和你的完整歌的低码率方式之间，我会选前者
... these two approaches are for different issues of streaming ...
indeed . This first one is for delay, the second one is for the
limitation of link capacity ."
I guess you assume the link capacity is not an issue. it is not always
true ... Approach II is for capacity limited situations ... more extremely
it means, your 增强数据 possibly never come through ... because the link
outage is too high to deliver high-rate contents.
Your know why Apple is making this invention instead of directly using
youTube approach. Besides patent/loyalty/legal issues, one reason I guess
is Apple envision it is facing different challenges to youTube, since a
significant of iFans will use its iCloud through mobile network in the
near future ... The outage of mobile network will be going up and
capacity per user will be going down, when the number of mobile users
increases .

【在 f*******5 的大作中提到】

: 我问你，用户一下拖到2分种得点，你怎么反应？
: 1）先播本地低码率数据？有噪点
: 2）等增强数据？有延迟，那存低码率数据的意义何在,尤其省不了多少带宽。

f*52011-05-19 07:05

27 楼

卫星电视下雨的时候会因为信号差显示信号中断，你愿意看各种马赛克，听各种啸叫?
一首听惯了的高保真的歌,走了几步变美国之音短波质量了,我不知道你能不能听的下去.
苹果做到自己数据中心跟的上,花大价钱用个好的cdn就行了.

【在 s*********n 的大作中提到】

: " 在存每首歌开头多少秒完整数据的方式和你的完整歌的低码率方式之间，我会选前者
: ... these two approaches are for different issues of streaming ...
: indeed . This first one is for delay, the second one is for the
: limitation of link capacity ."
: I guess you assume the link capacity is not an issue. it is not always
: true ... Approach II is for capacity limited situations ... more extremely
: it means, your 增强数据 possibly never come through ... because the link
: outage is too high to deliver high-rate contents.
: Your know why Apple is making this invention instead of directly using
: youTube approach. Besides patent/loyalty/legal issues, one reason I guess

f*52011-05-19 07:05

28 楼

对应第二种情况的选项会是有些专辑用户会选择全存在设备上

...

【在 s*********n 的大作中提到】

s*n2011-05-19 07:05

29 楼

CDN is not the bottleneck ... it is VZW and ATT network .
BTW, you can always cache a better quality sound track instead of 8kbps
... if you can download the APP, public radio, and pick a 32k radio
station ... the quality isn't that bad as you might think .
I think Android has this app too.

去.

【在 f*******5 的大作中提到】

: 卫星电视下雨的时候会因为信号差显示信号中断，你愿意看各种马赛克，听各种啸叫?
: 一首听惯了的高保真的歌,走了几步变美国之音短波质量了,我不知道你能不能听的下去.
: 苹果做到自己数据中心跟的上,花大价钱用个好的cdn就行了.

s*n2011-05-19 07:05

30 楼

"有些"专辑用户会选择全存在设备上 .....?
How do you know when it will happen? Flash forward?

【在 f*******5 的大作中提到】

: 对应第二种情况的选项会是有些专辑用户会选择全存在设备上
:
: ...

f*52011-05-19 07:05

31 楼

你认为netflix关心用户用什么isp么。

【在 s*********n 的大作中提到】

: CDN is not the bottleneck ... it is VZW and ATT network .
: BTW, you can always cache a better quality sound track instead of 8kbps
: ... if you can download the APP, public radio, and pick a 32k radio
: station ... the quality isn't that bad as you might think .
: I think Android has this app too.
:
: 去.

f*52011-05-19 07:05

32 楼

”有些专辑”。

【在 s*********n 的大作中提到】

: "有些"专辑用户会选择全存在设备上 .....?
: How do you know when it will happen? Flash forward?

s*n2011-05-19 07:05

33 楼

I guess .... it is YES ... if a majority of them uses iPhone watch the
video through mobile network .... and care about the delay ....

【在 f*******5 的大作中提到】

: 你认为netflix关心用户用什么isp么。

f*52011-05-19 07:05

34 楼

有空听听北京音乐台，你会听出差别的

【在 s*********n 的大作中提到】

f*52011-05-19 07:05

35 楼

你贴子里用guess太多了

【在 s*********n 的大作中提到】

: I guess .... it is YES ... if a majority of them uses iPhone watch the
: video through mobile network .... and care about the delay ....

s*n2011-05-19 07:05

36 楼

I am sure there is difference ... but the reasons are ...
What is the rate? What is the device? are you using earbud or speaker? Is
it because of jittering or the low quality ? I am interested in know the
reasons ....

【在 f*******5 的大作中提到】

: 有空听听北京音乐台，你会听出差别的

s*n2011-05-19 07:05

37 楼

I guess you are right ... :P

【在 f*******5 的大作中提到】

: 你贴子里用guess太多了