Froyo audio quality problems acknowledged by Google, fix coming (eventually)

[Caitlyn McKenzie]

First, a fix for the audio quality in AAC+ streams (Pandora, etc) has been commited to the Froyo branch:

android.git.kernel.org Git - platform/frameworks/base.git/commit

The bug originally filed for reference (see comment 140 for Google's acknowledgment that the above commit is the fix):

Issue 9308 - android - eaac+ and aac+ decoding sound quality problems (Android 2.2) - Project Hosting on Google Code

Just letting you all know that we should see a fix incoming, and for Froyo. As to WHEN we'll see this is unknown (especially with the lag on patches through HTC), but it is on the way.

 

[Flip]

Nice even though I don't have a problem with my phone

 

[Caitlyn McKenzie]

To anyone reading this thread from the Android Central article:

I do not share Jerry's opinion on this matter. AAC+ is not a legacy codec, and anyone who expects Pandora and other app developers to re-encode their entire music library for a codec they were told Froyo would support is insane.

I sincerely hope that Jerry revises the article!

 

[NeoteriX]

I sincerely hope that Jerry fixes his article, although based on past mistakes of the Android Central staff (See also: Flash 10.1 on Eclair fake, and breaking everyone's OTA upgrade to 2.2) going unfixed, I doubt he will.

:rollseyes:

There's nothing to "fix" when what is being articulated is an opinion.

Let it be said that the re-encoding of entire media libraries has been done before -- Google went through the effort of re-encoding all of Youtube to H.264, in part to provide better HTML5/non-Flash support to devices that refused to provide Flash support (*cough* Apple), and is doing so again to provide support for its new WebM format.

Now clearly Google has more resources to bring to bear than Pandora or Slacker, but I'm just showing that this kind of thing is not unprecedented. Furthermore, Video is a lot more space and processor intensive than music is. Though Google has more resources, it arguably requires more to transcode its entire youtube library.

 

[Cory Streater]

Alright guys, Vincent and I hashed this out via a PM. I've cleaned this up and am reopening it. I think we mutually understand each others points - and FWIW I am not trying to throw my weight around. I was defending Jerry to the same standards I would defend any other forum member. If anyone EVER disagrees with me or is under the impression that I am trying to be some sort of dictator, 99% of the time things can be resolved via private messaging.

 

[Caitlyn McKenzie]

Alright guys, Vincent and I hashed this out via a PM. I've cleaned this up and am reopening it. I think we mutually understand each others points - and FWIW I am not trying to throw my weight around. I was defending Jerry to the same standards I would defend any other forum member. If anyone EVER disagrees with me or is under the impression that I am trying to be some sort of dictator, 99% of the time things can be resolved via private messaging.

Just chiming in to agree and that he isn't blowing smoke.

 

[Kasracer]

Let it be said that the re-encoding of entire media libraries has been done before -- Google went through the effort of re-encoding all of Youtube to H.264, in part to provide better HTML5/non-Flash support to devices that refused to provide Flash support (*cough* Apple), and is doing so again to provide support for its new WebM format.

Google has never done this. Instead, they provide a way to stream the formats from one into another and then cache them. Going through and converting everything would be pointless as there will always be other codecs coming out.

 

[Nuevo]

Pandora Audio Quality: Pre-Froyo and Post-Froyo

As a newbie to Evo, Android, and smartphones in general, I've been astonished by the power vested in that little black slab.

Considering my high expectations, there have been disappointments, too.

Pandora is a good example of both the pluses and the minuses of a combination of hardware/OS/App (Evo/Android/Pandora) in one package.

Pro: The Pandora concept is staggering in concept and execution. Possibly a Sirius/XM killer and more.

Con: The audio quality is poor. I'm talking PRE-FROYO. I have a semi-decent third party sound system in my car through which Sirius sounds pretty good. Not great, but I can be happy with it. Can't say the same for Pre-Froyo Pandora.

Pandora offers an upgraded audio version ($$) which is also commercial free. I was ready to sign up until I discovered that the Pro version's upgraded audio doesn't work over 3G! (Provides commercial elimination only) WHY NOT???????

Now, Post-Froyo and Jerry Hildenbrand's article and comments: I can't speak intelligently to the technical details or the politics. For instance, I don't know whether Pandora's encoding is done on the fly or is fundamentally entwined in their archive. But if it IS "on the fly," and if the Froyo codec is qualitatively superior to the current codec, then WHY WOULDN'T PANDORA CHANGE?

The irony to me is that you would expect Pandora to press for higher audio quality at the expense of bandwidth. You would expect Sprint to encourage app developers to squeeze their bits into less bandwidth. And, yet, with the Froyo/Pandora debacle, just the opposite seems to be happening.

I don't get it.

 

[Caitlyn McKenzie]

Google has never done this. Instead, they provide a way to stream the formats from one into another and then cache them. Going through and converting everything would be pointless as there will always be other codecs coming out.

What you just explained doesn't exist, for a multitude of reasons.

A. Converting to other formats on the fly would be extremely CPU intensive, making the number of servers needed to run YouTube exponentially larger. Whole servers cost a LOT more than a few extra commodity hard drives.
B. They do convert them as this is why it takes a while for videos to have other formats (for example, when you upload a video, 360p version will always be the first, followed by 480p, followed by HD options and HTML5/WebM options). If it was streaming, these would appear instantly.
C. Most of the higher end formats wouldn't even be encode-able at real-time speeds on the servers Google uses.

 

[Caitlyn McKenzie]

Con: The audio quality is poor. I'm talking PRE-FROYO. I have a semi-decent third party sound system in my car through which Sirius sounds pretty good. Not great, but I can be happy with it. Can't say the same for Pre-Froyo Pandora.

For free it's hard to argue with 128kbps AAC quality. I think someone's ears are playing with them.

(Note: there are a few songs which aren't encoded properly and sound bad. This is not indicative of the whole library.)

Pandora offers an upgraded audio version ($$) which is also commercial free. I was ready to sign up until I discovered that the Pro version's upgraded audio doesn't work over 3G! (Provides commercial elimination only) WHY NOT???????

So it doesn't skip?

Now, Post-Froyo and Jerry Hildenbrand's article and comments: I can't speak intelligently to the technical details or the politics. For instance, I don't know whether Pandora's encoding is done on the fly or is fundamentally entwined in their archive. But if it IS "on the fly," and if the Froyo codec is qualitatively superior to the current codec, then WHY WOULDN'T PANDORA CHANGE?

It's not done on the fly. They store it all. No one would encode that much on the fly, it would cost ridiculous amounts in server CPU.

Also, the quality differences between them are negligible at best. It's not a legacy codec, in reality.

The irony to me is that you would expect Pandora to press for higher audio quality at the expense of bandwidth. You would expect Sprint to encourage app developers to squeeze their bits into less bandwidth. And, yet, with the Froyo/Pandora debacle, just the opposite seems to be happening.

I don't get it.

I don't think you get the actual situation

 

[Kasracer]

What you just explained doesn't exist, for a multitude of reasons.

A. Converting to other formats on the fly would be extremely CPU intensive, making the number of servers needed to run YouTube exponentially larger. Whole servers cost a LOT more than a few extra commodity hard drives.
B. They do convert them as this is why it takes a while for videos to have other formats (for example, when you upload a video, 360p version will always be the first, followed by 480p, followed by HD options and HTML5/WebM options). If it was streaming, these would appear instantly.
C. Most of the higher end formats wouldn't even be encode-able at real-time speeds on the servers Google uses.

Whoa, slow down there bucko. Please re-read what I wrote. They have software that streams videos into other codecs, not a stream encode to an end user (that would be insane).

It's very simple, would you want the ability to stream any of your file formats into what you need, save and store that or would you want to convert your entire library each time you need to support a new codec? This is also one of the reason why the videos available in the YouTube mobile application are NOT the same as the ones on the site; there are many missing.

Though, I'm pretty sure Google has the ability to stream-encode videos to end users. I believe in an interview they had said they can re-encode an HD video almost instantly with their distributed system.

 

[Caitlyn McKenzie]

Whoa, slow down there bucko. Please re-read what I wrote. They have software that streams videos into other codecs, not a stream encode to an end user (that would be insane).

It's very simple, would you want the ability to stream any of your file formats into what you need or would you prefer to re-encode everything every single time? This is also one of the reason why the videos available in the YouTube mobile application are NOT the same as the ones on the site; there are many missing.

Okay, I get one part, but then you just went loony at the other part.

When you say stream, you actually mean re-encode. Because that's what you're doing. You're taking the original encoded video that was uploaded, and you're re-encoding it to a new format, be it 360p default, 720p hd, etc.

What you were saying about "re-encoding everything" makes no sense, since I can't fathom any situation where that would even come up. Why would a video saved in one format have any influence on other formats that are created later from a specific source encode?

The only thing I can think of is you're taking the "re-encoding everything" to the extreme to mean every format of every video, instead of the mentioned every video.

Edit: The reason I'm very specific to avoid saying stream, because you can't simply take a video stream out of, say, a 360p mp4 and just place it in a new container for 720p. The stream is still going to be 360p. You have to go from the source, take ITS stream, and re-encode it to get the format and codec you want.

 

[Kasracer]

When you say stream, you actually mean re-encode. Because that's what you're doing. You're taking the original encoded video that was uploaded, and you're re-encoding it to a new format, be it 360p default, 720p hd, etc.

Think of TVersity. It's a software application that takes one source and sends it to another device as another source. It's not a very good re-encode. That's what Google does.

What you were saying about "re-encoding everything" makes no sense, since I can't fathom any situation where that would even come up. Why would a video saved in one format have any influence on other formats that are created later from a specific source encode?

I don't know what this means. I agree, why would a video saved in one format have influence on other formats created from the source?

You wouldn't re-encode a video that's already encoded in X format if you need it in Y format.

Edit: The reason I'm very specific to avoid saying stream, because you can't simply take a video stream out of, say, a 360p mp4 and just place it in a new container for 720p. The stream is still going to be 360p. You have to go from the source, take ITS stream, and re-encode it to get the format and codec you want.

Why avoid it? You're talking about something no one else is talking about, lol. I'm talking about the source video, not taking a re-encoded video made from source, then using that video to "stream" it. That sounds ******ed and isn't mentioned anywhere...

 

[Caitlyn McKenzie]

Think of TVersity. It's a software application that takes one source and sends it to another device as another source. It's not a very good re-encode. That's what Google does.

*facepalm*

The differences are a little bit more specific than you're trying to make it out to be.

A. TVersity has a different goal. It attempts to re-encode a file quickly enough so that you can play it in real-time. Thus, the quality is reduced in exchange for speed.
B. It's still a re-encode, the only difference is is what you're doing with the end result. TVersity's only keeping the encoded file around long enough to play it.
C. Google re-encodes for different reasons. They do value speed, but they value space far more. Thus, the reason for lower quality on YouTube is to keep the filesize down, both for themselves and for the user. TVersity doesn't need to worry about this since almost all use cases involve LAN connections.

You wouldn't re-encode a video that's already encoded in X format if you need it in Y format.

Yes you would, because you would have to. You can't just plop X into Y and expect it to conform to Y.

If you are trying to make a point with this, be far more specific with an example next time. Give me codec names and such.

Why avoid it? You're talking about something no one else is talking about, lol. I'm talking about the source video, not taking a re-encoded video made from source, then using that video to "stream" it. That sounds ******ed and isn't mentioned anywhere...

I don't even know what you're saying here but let me just make it clear, this IS what Google does:

A. User uploads a source video.
B. Google re-encodes the video (the source is already encoded in one of a bazillion different formats YouTube accepts) into 360p, the default YouTube format that is most compatible.
C. For every subsequent video format after that, be it 480/720p, mobile, HTML5/WebM, etc, they take the source video and re-encode it to the formats desired.
D. As Google desires new formats, they instruct their render farms to re-encode from the source files any additional formats they need. They do not touch the ones they've already encoded, as there's no reason to (except to remove if it's been obsoleted).

 

[Kasracer]

Yes you would, because you would have to. You can't just plop X into Y and expect it to conform to Y.

If you are trying to make a point with this, be far more specific with an example next time. Give me codec names and such.

lolololol

Can you stay on topic, please? We were talking about going from Source -> X and Source -> Y and I told you it wouldn't make sense to go from X -> Y. It sounded like you agreed...and now you're back to using it.

I don't even know what you're saying here but let me just make it clear, this IS what Google does:

A. User uploads a source video.
B. Google re-encodes the video (the source is already encoded in one of a bazillion different formats YouTube accepts) into 360p, the default YouTube format that is most compatible.
C. For every subsequent video format after that, be it 480/720p, mobile, HTML5/WebM, etc, they take the source video and re-encode it to the formats desired.
D. As Google desires new formats, they instruct their render farms to re-encode from the source files any additional formats they need. They do not touch the ones they've already encoded, as there's no reason to (except to remove if it's been obsoleted).

That's what I said (well, almost; they don't re-encode it to all formats; there are some videos they leave in certain formats and restrict from being accessed over the API)!

Jesus. I thought I was being a bit of a troll but maybe I had it backwards, lol.

 

[Artaxiad]

Short-time lurker, first time poster.

I am and EVO owner and was hamstringed by this audio quality problem in the 2.2 updates. I've done the usual moaning to whatever support places I could go.

I'm not sure how this affects your disagreement with the author of the article on the main page, Vincent Law, but it appears that the developers of apps are the ones having to change things. Personally, I am inclined to agree that AAC is not legacy, and that Google fudged up with this issue.

I subscribe to MOG, and their streaming service sounded like trash with the update came. Today, however, I was e-mailed by a someone at MOG asking if I was interested in testing the next release candidate for their app. They fixed (worked around?) the AAC issues. Pandora also pushed out an update to their app today, but I haven't had a chance to test it out to see if they also found a way to work around.

food for thought.

 

[Caitlyn McKenzie]

They're not the ones that need to change things, since the whole purpose of this thread was pointing out that Google themselves fixed the issue in source, and that eventually we'd see that fix in a patch.

 

[Nuevo]

Quote:
Originally Posted by Nuevo View Post

Con: The audio quality is poor. I'm talking PRE-FROYO. I have a semi-decent third party sound system in my car through which Sirius sounds pretty good. Not great, but I can be happy with it. Can't say the same for Pre-Froyo Pandora.

For free it's hard to argue with 128kbps AAC quality. I think someone's ears are playing with them.

Vincent, I have no desire to engage in a shouting match with you. I must point out, though, that Pandora's mobile stream encoding is not 128 kbps as you suggest above, just before you malign my hearing. In fact, it never exceeds 64 kbps. Since your ears are unable to verify this, perhaps you should ask Pandora. That's what I did.

Yes, Pandora's encoding rates are higher for internet devices, and for home computers when a premium is paid (Pandora One). Those encodings provide a clearer, more transparent sound, but what we are talking about here is the Evo.

 

[Caitlyn McKenzie]

Vincent, I have no desire to engage in a shouting match with you. I must point out, though, that Pandora's mobile stream encoding is not 128 kbps as you suggest above, just before you malign my hearing. In fact, it never exceeds 64 kbps. Since your ears are unable to verify this, perhaps you should ask Pandora. That's what I did.

You ignored the fact that there is 2 options for audio playback in Pandora. "Normal", which is likely the 64kbps you reference, and "High", which sounds infinitely better and is 128kbps.

(one needs only watch the traffic on the device to see this is true. It will hover right around 128kbps after it fills the cache)

Also, I am not talking about Pandora One when I say "High". It's in the options, and yes it makes a difference. Pandora One is 192kbps and only available on PCs as you say.

 

[Nuevo]

You ignored the fact that there is 2 options for audio playback in Pandora. "Normal", which is likely the 64kbps you reference, and "High", which sounds infinitely better and is 128kbps.

Why speculate when you can get correct info from the horse's mouth? With the kind permission of Jonathan in Customer Support at Pandora, I quote his 8/11/10 emailed comment on Pandora's Evo bitrate:

"Mobile devices receive a variety of different rates depending on the capability of the device and the network they are on, but never more than 64k AAC+."

If you need further clarification on this, please contact Pandora directly.