Since you guys changed to using xxxx.48k.v2.m4a (from xxxx.64k.m4a), my program hasn't been able to playback any music. I don't know webOS can't handle this format but it keeps giving me a decode error.
I don't know if it has to do with the 48k rate or maybe it's just a naming issue of the file, but for whatever reason, it doesn't work.
This is really bad for me.
Regards,
Gabe Testa
Fyi 48k is kind of an oddball sample rate to use and is going to cause degradation of audio quality both during the ingestion phase when people upload their files to 8tracks.com, and during playback as it is going to get sample rate converted from 44.1 on ingest and converted again back to 44.1 on playback for most systems.
Better to use 44.1 all the way through your system IMO.
Joel
Sent from my iPhone
Sent from my iPhone
On Sep 19, 2011, at 9:03 AM, Gabriel Testa <gabe....@gmail.com> wrote:
So aside from my stupid remark about sample rates, it appears that the
roku hardware is not capable of playing back the "High Efficiency"
format. Any chance you guys can revert back to the old format? I'm
still testing, but so far, this appears to be the case.
- Joel
I'm really sorry for breaking your apps. We tested the new files on
browsers, flash, android and iPhone but I should have offered sample
files ahead of time to allow you to check it works.
In order to make sure audio plays consistently and that it loads fast
on slower connections, we reencode all files to HE-AAC 44.1kHz mpeg4.
For the past 2 years, we've been using 64kbit / 44.1kHz HE-AAC encoded
with Orban-CT on Windows, we've had 2 ongoing issues with it:
- Android 2.2 and under don't decode properly
- on iPhone, audio quality is terrible.
Because of these issues, we switched to the industry standard HE-AAC
encoder by Fraunhofer:
http://www.iis.fraunhofer.de/en/bf/amm/produkte/audiocodec/audiocodecs/heaac/
We currently store 4+ million files so it's a big job to re-encode
everything. At 48kbit the sound quality was so good that we took the
opportunity to reencode all 4+ million files to a lower bitrate, hence
reducing file sizes, load time, and costs on bandwidth and storage. It
was a tough choice but we just couldn't hear a difference in sound
quality and doubt that many people will hear any differences either.
Now, on getting playback working again on your platforms. It's going
to be tough for us to switch encoders but maybe it's just a matter of
fine-tuning settings. Tomorrow, I'm going to set up an "AAC decoding
test mix" with differently encoded files so you can tell me which ones
work.
Let's get it all working soon,
Remi
--
Rémi Gabillet
CTO & co-founder, 8tracks
http:8tracks.com/remi
I'll follow up with you guys in a couple hours.
-Joel
Sent from my iPhone
I just manually fixed all 9 tracks on this mix, can you please try playing them:
http://8tracks.com/remi/happy-2nd-birthday-8tracks
http://8tracks.s3.amazonaws.com/tf/000/474/069/20959.48k.v2.m4a
Joel, can you tell me if the mix works on Roku?
Just tested, unfortunately, it still throws the same error. Can you
put that range of test files you mentioned earlier up on AWS and email
the links, and include a few of the older file types for a baseline?
Thanks
- Joel
Here are a bunch of files you can play with, let me know which ones
work or don't work, thanks!
http://8tr.tmp.s3.amazonaws.com/testfiles/you.64k.old.m4a
http://8tr.tmp.s3.amazonaws.com/testfiles/you.56k.m4a
http://8tr.tmp.s3.amazonaws.com/testfiles/file.2.4.64k.m4a
http://8tr.tmp.s3.amazonaws.com/testfiles/file.5.4.64k.m4a
http://8tr.tmp.s3.amazonaws.com/testfiles/file.5.1.64k.m4a
http://8tr.tmp.s3.amazonaws.com/testfiles/file.5.2.64k.m4a
http://8tr.tmp.s3.amazonaws.com/testfiles/file.129.4.48k.m4a
http://8tr.tmp.s3.amazonaws.com/testfiles/file.2.4.48k.m4a
http://8tr.tmp.s3.amazonaws.com/testfiles/file.29.4.48k.m4a
http://8tr.tmp.s3.amazonaws.com/testfiles/file.5.4.48k.m4a
http://8tr.tmp.s3.amazonaws.com/testfiles/file.132.4.48k.m4a
FYI the numbers in file names are, in order, aot, tms and bitrate:
-aot <int> Audio object type (AOT):
------------------------
2: MPEG-4 AOT 2 (MPEG-4 AAC LC).
5: MPEG-4 AOT 5 (MPEG-4 AAC SBR, i.e. AAC LC + SBR).
29: MPEG-4 AOT 5 (MPEG-4 PS, i.e. AAC LC + SBR + PS).
129: MPEG-2 AAC, LC Profile (corresponds to
MPEG-4 AOT 2, but no support for the PNS
tool).
132: MPEG-2 AAC, LC Profile + SBR (corresponds to
MPEG-4 AOT 5, but no support for the PNS
tool).
-tms <int> Sets the transport format.
Transmux (bitstream) type:
--------------------------
0: Raw (plain access units; not recommended).
1: ADIF (MPEG-2).
2: ADTS (MPEG-2).
3: 3GPP file format.
4: MPEG-4 file format (default).
Until we come up with a solution, you may want to use the old files by
substituting 48k.v2.m4a by 64k.m4a.
Alternatively, if you give me the user-agent string for your app, I
can return old file paths directly.
Remi
if you can filter on user-agent string, can your filter on a partial?
the roku User-Agent includes the firmware version info, and the build
info and a few other things.
The first part is always the same though, "Roku/DVP-":
User-Agent: Roku/DVP-3.0 (013.00E02219A)
User-Agent: Roku/DVP-4.1 (024.01E01250A)
other versions known to be in the wild are 2.9 (90% of the Roku
devices out there) and 4.2 (90% of the Roku2 devices).
FYI Gabe, if you can have your software retrieve a file, any file,
from your own website, then check the log files for the User-agent
string.
- Joel
Since we don't have a clear solution yet, I put in place the
user-agent logic that will serve old aac files for strings matching:
"Roku", "webOS" or "Pre/"
Let me know how that works...
Remi
- Joel
I'm not sure how long we can maintain the old files so let's try to
find a solution that would work with the new encoder. Joel, can you
still contact Roku and let me know what they say about the newer
files?
- Joel