Garbled AAC stereo stream with direct play on Roku 3



I have MKV Blu-ray rips that I've been running through ffmpeg in order to encode the video to H.264 and add an AAC-LC stereo audio stream so that they will direct play on Plex on my Roku 3 (4230R). So far this has worked out well (and freed up over 2TB of disk space and counting), with one exception: The stereo streams sound garbled or crackly, particularly with dialog, when direct playing the files. The garbling isn't consistent when watching any movie, it comes and goes.

The stereo channel is only garbled sounding when direct playing the files on Plex on the Roku. If I watch one of the movies using the Plex web player or in VLC media player, the stereo audio streams sound just fine, so I know there's nothing wrong with the audio stream itself. Additionally, if I switch to one of the other audio streams in Plex on the Roku, such as the DTS/DTS-MA streams, Plex transcodes it to AAC stereo and it sounds just fine, which is the current workaround.

My Plex Media Server and Plex Roku channel are both up to date, as is the Roku firmware.

Any ideas?

Thanks in advance.


Anyone? I've not been able to eliminate the issue. The only thing that works is to change the stream to one of the DTS or AC3 streams, which forces Plex to transcode to AAC stereo.

Let me know if you need any more information.


What are you using to transcode your media? Can you post a sample mediainfo of a file? How about a sample?


I had noticed that I occasionally had crackly audio on a stereo AAC track when I added a stereo audio track to ripped files. I actually add the stereo track as the first audio track, and a surround track as the second audio track so that the Roku will automatically select the right one depending on the system it's connected to.

I found using this command for ffmpeg seemed to eliminate the crackle, and also slightly increased the volume for the stereo track which I thought was a little low. It might work for you with a little editing for your command line...

ffmpeg -i ORIGINAL_VIDEO_FILE -ac 2 -vn -map_metadata -1 -map_chapters -1 -af "pan=stereo|FL=0.71*FC+FL+BL|FR=0.71*FC+FR+BR" -b:a 192k STEREO_AUDIO.m4a

I then use ffmpeg to remux the file with the new audio track, the original surround audio and the original video track, usually as an mp4.


I apologize for the very late reply. I've been busy with other projects and this one got put on the back burner.

I appreciate the feedback, leelynds. I tried your ffmpeg example using the audio filter, but the resulting AAC audio stream too has the crackly audio. Though I didn't output it to an audio file and remux, I simply mapped it to the output MKV file, where it still crackled when direct streamed on the Plex Roku app. It did not have the crackly audio when played in VLC media player, which is consistent with all the other files that exhibit this problem. This is the command line used:

ffmpeg -i "input file.mkv" -map 0 -map a:0 -codec:a:0 aac -ac:a:0 2 -af "pan=stereo|FL=FC+FL+BL|FR=FC+FR+BR" -b:a:0 192k -metadata:s:a:0 title="Stereo" -codec:v copy -codec:s copy -f matroska "output file.tmp"

To provide some more information as requested by drinehart: I was using ffmpeg to bulk transcode MKV Blu-ray (and some DVD) rips to be direct-play compatible with the Plex Roku app. This included converting the video to H.264 using a crf of 20 (which mostly keeps the bitrate at 20 mbps or less) and creating an AAC stereo (or mono, depending on the source movie) stream. The following is generally the ffmpeg command line used (though I used -crf 18 for DVDs, and -tune animation for some other inputs):

ffmpeg -i "input file.mkv" -map 0 -map a:0 -codec copy -codec:v libx264 -preset medium -crf 20 -tune film -codec:a:0 aac -ac:a:0 2 -b:a:0 192k -metadata:s:a:0 title="Stereo" -f matroska "output file.tmp"

This will copy all streams from the input file to the temporary output file, and will additionally create an AAC stereo stream as the first audio track with the label 'Stereo'. After the encoding process was done, the input file would be replaced by the temporary output file. This way the change would be transparent to Plex since the encoding process was happening in the Plex library.

If I play the affected MKV files locally on my desktop PC using VLC media player the crackly audio is not present when playing the AAC stereo streams. Additionally, I'm able to direct stream via the Plex Android app, and it too can play the AAC stereo streams without the crackling.

Interestingly, if I use Handbrake to do my encoding and create an AAC stereo stream, it does not have the cracking audio when direct played on the Plex Roku app.

As I indicated in my previous post, the workaround to this issue is to simply select one of the other streams in the movie, such as the DTS or AC3 tracks, which forces Plex to transcode it to AAC stereo, and results in clean (no crackling) audio, though it's usually quieter. While this is an easy workaround, it has to be done manually for each movie as Plex defaults to selecting the first audio stream, which is where I purposely had ffmpeg place the AAC stereo stream.

My copy of ffmpeg was upgraded several times during this bulk transcoding (which took several months), but the files all exhibit the same behavior regardless of ffmpeg version. The last version I used was: ffmpeg-20170116-e664730-win64-static

Sorry for the long winded post, but trying to give as much information as possible. Let me know if there's any other info I can provide.


I 'pre-process' all the audio tracks in material I create so it comes up to 89db (finicky TV/Audio system likes 'the sweet spot'). An errant click in Xmedia Recode recently went unnoticed for several days wherein it was producing AAC 2.0 (Main) audio instead of the old standard AAC 2.0 (LC) that is compatible with everything on the Planet. This resulted in audio that sounded almost exactly as is described above (I called it 'the comforting sounds of a train wreck').

My Handbrake only does AAC 2.0 (LC) so files coming directly off that were fine, but as soon as they went through Xmedia Recode they were hosed.

It took me a while to figure out what had happened and Xmedia Recode has a habit of 'remembering' what you have done (in error, in my case) and repeating that for everything that follows. It freaked me out. If I forced a full transcode the audio was fine, but in Direct Play it was 'fingernails on a blackboard'.

The moral of the story is that I did finally figure it out, converted those audio tracks back to AAC 2.0 (LC) and all was again as it was.

A quick inspection with MediaInfo or some other file inspection method should reveal what 'flavor' of AAC these files possess. Anything other than AAC (LC) will be bad news. The Roku app will identify the 'flavor' and be clearly visible in the item's pre-play screen - in the big window right above the subtitle line.


The AAC stream that is created is indeed AAC LC, as revealed by MediaInfo (I knew this beforehand but double-checked just to be sure). Also, the Plex Roku app identifies the stream as 'AAC-LC Stereo'. The Plex web player only identifies the stream as 'AAC Stereo', same with the Plex Android app and Plex Windows app.

The issue I'm having doesn't seem to be the same as the one you're describing. The 'crackling' (or maybe better described as 'garbling') that I hear is slight most of the time, and is most obvious when wearing headphones (which is how I primarily watch movies) via the Roku remote's headphone jack, but depending on the scene in the movie, it can be heard on the built-in TV speakers as well. It only manifests itself when the movie is direct played.

In my previous post yesterday I mentioned that movies I've transcoded with Handbrake to include the AAC stereo stream do not have this problem. Well this appears to be untrue, as last night I watched a movie on Plex Roku that I transcoded in Handbrake, and the AAC LC stream did indeed develop the crackling/garbling, so I switched it to the DTS stream to force Plex to transcode the audio, and all was fine for the rest of the movie. The problem was not present when viewing the movie in VLC media player or when direct played on the Plex Android app either, which is consistent with the other movies that have this problem.

There appears to be nothing wrong with the AAC LC stereo stream in these files, as they don't have this crackling/garbling problem in VLC media player, or when direct played on the Plex Windows app, the Plex web player, or the Plex Android app. It seems to be an issue specific to direct playback of AAC stereo streams on the Plex Roku app. This is not limited to just movies either. TV shows that I ran through ffmpeg using the command mention in my previous post also have this issue.


So - the files you create are OK and the files created by someone who is not you are bad?

Ok. Got it. I think we're narrowing in on the issue here....

You seem to be doing ok, but Dr. Frankensteen out there in the world somewhere doesn't have your skill set.

My issue was easy to identify as a problem because the melodic tones of Train Wreck caused aural bleeding and were easily repaired with another run through Xmedia Recode with the correct settings.

I hope you locate and fix your issue.


No, all my files were all created by me. I do my own rips and encodes.

These files have a slight crackling or garbling sound when direct played on the Plex Roku app with the AAC LC stereo stream selected. They don't sound this way when played directly in VLC media player, or direct played in the Plex Windows app, Plex Android app, or Plex web player with the AAC LC stereo stream selected.

It's an issue specific to direct playing MKV files with AAC LC stereo streams on the Plex Roku app.


I see.... the plot thickens.

Well, the good news is that when @ljunkie sees and responds to this thread we'll begin to know a lot more about it than we do now and the solution will be nearer. I guess in the meantime you could remux to an MP4 file if that indeed cures the issue - retaining a 'broken' version of the file so @ljunkie can have a look at it.

I have seen some fairly strange playback issues with the newest PMS version. Perhaps this is one of them.

Edit - For instance:

I've got a full season of a documentary show I just recorded/converted just like I've done thousands of before and on my Roku 3 the audio is out of sinc by at least 1.5 seconds. The same files play perfectly on my AFTV app (which is, Amazing) as well as every other Plex app I have. Something is up somewhere.


Apparently, I spoke too soon with my suggestion to get rid of crackle. Most of my stuff has an AC3 surround track, that the Roku automatically selects rather than the AAC audio. But the other night I was watching something with a stereo only AAC track, and the crackle returned. Problem is, it's not consistent, and if I happen upon the bad audio, backing out and resuming fixes it. I'm going to assume the Roku transforms the audio because I know my receiver does not do AAC audio - I believe it comes thru as PCM. Maybe something in the method use by the Roku gives us the bad audio, or possibly a bad connection with the HDMI cable in this circumstance...


I have the same problems with Roku 2's (2015 models). AAC LC Stereo.

Media has been ripped via various methods over the years... makemkv, handbrake, xmedia, etc... Originally saved in MKV containers, but remuxed to m4v (some 3rd party scripts on Linux make it very easy to quickly/easily add 2-ch audio while simply remuxing h264 since most of my rips only included 5.1-ch audio).

Did anyone ever get a solid resolution to this?


The only time I have seen this on my Roku 2 2015 is when AAC MAIN was selected instead of AAC LC. I have not had this issue at all using LC. I do not use volume boost (I am not at my Roku and cannot remember the exact terms), and if that is set too high it can cause these issues.


@drinehart said:
The only time I have seen this on my Roku 2 2015 is when AAC MAIN was selected instead of AAC LC. I have not had this issue at all using LC. I do not use volume boost (I am not at my Roku and cannot remember the exact terms), and if that is set too high it can cause these issues.

Yep, same here. It was a bad day in Juicetown when that Xmedia Recode setting got changed somehow and took me a few days to figure it out. AAC Main = bad juju.

Ever since the famous Roku 4 if the audio 'clips' somewhere above 89db (don't know the critical threshold) undesireable results may occur. I bring everything up to 89db with XR and so far, so good (with AAC-LC, at least).


@JuiceWSA - same here. All the way around.


@kaymer327 said:
I have the same problems with Roku 2’s (2015 models). AAC LC Stereo.

Media has been ripped via various methods over the years… makemkv, handbrake, xmedia, etc… Originally saved in MKV containers, but remuxed to m4v (some 3rd party scripts on Linux make it very easy to quickly/easily add 2-ch audio while simply remuxing h264 since most of my rips only included 5.1-ch audio).

Did anyone ever get a solid resolution to this?

No, I still have the problem. The only resolution I’ve found is to force Plex to transcode to AAC-LC stereo by selecting one of the other audio streams. This isn’t a terrible solution, as very little CPU is used to transcode the audio. But it’s not the ideal solution (ideally it should Just Work). This issue only happens on the Plex Roku app on my Roku 3 (4230R). It doesn’t happen when watching movies on any other Plex apps (I’ve tried Plex Android, Plex Web Player, Plex Windows app) or in VLC media player. I have not tried Plex on one of my older Roku 2 XS devices.

The issue is present in movies transcoded by Handbrake as well, though it’s not as consistent as those transcoded by ffmpeg.

Not sure what AAC Main is, but as far as I can tell these streams are all AAC-LC. Here’s a screenshot of media info from one of the files if it helps shed any light:


Has anyone found a fix to this yet? I'm having the same trouble across all of my Rokus. AAC Stereo sounds like the audio is under water...


Nope. I have 2 different threads with a lot of nothing going on... also in the Roku forum:

And in the Plex pass forum:

Too bad there isn't a real way to submit a bug report somewhere and get a real response. Would be nice...


I have to believe that it is really AAC_MAIN instead of LC. Those symptoms are the same when AAC_MAIN is used. Re-encode the audio with Xmedia Recode or whatever media converter you are comfortable with, and make sure to convert to AAC LC even if that is what it detects.


I'm not using AAC MAIN. It's most definitely AAC LC confirmed with media info:

Most if not all of my media gets an AC3 or DTS track re-encoded to AAC LC via ffmpeg (using sickbeard mp4 automator)