What stupid players are looking at the RSS feed instead of the file itself? And if they are looking at the feed, why are they not setting the length to 0 instead of se other crazy length? And why is the length 0 feed burner?
I tend to stream from the libsyn link in the RSS feed in my phone, and it's been showing up occasionally with the last few episodes. Unfortunately I don't listen regularly enough to tell which episodes it happens or doesn't happen on.
Ok, I'm adding the length data to the RSS feeds tonight. I still don't think this is going to work, and here is why. The length in the RSS enclosure is just the number of bytes the mp3 file takes up. It's equal to the content-length in the HTTP header. It would be impossible for any player, good or bad, to determine the play time of any mp3 based on this data because it does not include the bit rate. Doesn't matter if it's VBR or CBR. It is also possible for an enclosure to be any other kind of file, such as a non-mp3 codec audio file, a video, or even a pdf. What of the length then?
Do you have a duration tag? That's probably the one you need to add/fix.
<itunes:duration>
The content of this tag is shown in the Time column in iTunes.
The tag can be formatted HH:MM:SS, H:MM:SS, MM:SS, or M:SS (H = hours, M = minutes, S = seconds). If an integer is provided (no colon present), the value is assumed to be in seconds. If one colon is present, the number to the left is assumed to be minutes, and the number to the right is assumed to be seconds. If more than two colons are present, the numbers furthest to the right are ignored.
The duration tag would only help iTunes and not any other player. I use iTunes and do not have any problem whatsoever. Other people with iTunes do have a problem. There are also lots of people without iTunes who have a problem. The iTunes RSS tag definitely won't help them.
Pretty sure the problem is just people who for whatever reason can't handle VBR, and there's not much we can do about it.
No, I think you're doing something wrong with the headers, and I have evidence for it. In foobar2000, I can right click on one of the episodes it thinks is 4 hours, and in the Utilities submenu I can click on "Fix VBR MP3 header...". After clicking this, it thinks for a while, and then the file is corrected to its proper length.
Whatever encoding program you use is writing the headers incorrectly.
No, I think you're doing something wrong with the headers, and I have evidence for it. In foobar2000, I can right click on one of the episodes it thinks is 4 hours, and in the Utilities submenu I can click on "Fix VBR MP3 header...". After clicking this, it thinks for a while, and then the file is corrected to its proper length.
Whatever encoding program you use is writing the headers incorrectly.
If you need an open source alternative, a quick Google search finds this: http://mp3diags.sourceforge.net/ It looks like it would probably have that functionality.
If you need an open source alternative, a quick Google search finds this: http://mp3diags.sourceforge.net/ It looks like it would probably have that functionality.
I don't need an open source alternative. I need to see the code to figure out what it is doing.
Apparently the encoder in Adobe Audition does not write the XING header. If I can find some Linux code or command line app that does it, I can have the server automatically do the VBRfix before it uploads to libsyn.
This one seems really simple, and would probably do the job. You can see the code here; it's a single file.
This one is more complicated, but it has a more thorough validation and fixing process, which might be a good thing for you if it could catch an error before you upload the episode.
Alternatively, if you can switch your encoder over to LAME, I'm pretty sure it would correctly write the XING header; I expect it's also generally better.
Comments
I'd love to just ditch Feedburner and host our own feed directly, but you guys chew through a lot of bandwidth just for that little XML file.
<itunes:duration>The content of this tag is shown in the Time column in iTunes.
The tag can be formatted HH:MM:SS, H:MM:SS, MM:SS, or M:SS (H = hours, M = minutes, S = seconds). If an integer is provided (no colon present), the value is assumed to be in seconds. If one colon is present, the number to the left is assumed to be minutes, and the number to the right is assumed to be seconds. If more than two colons are present, the numbers furthest to the right are ignored.
Pretty sure the problem is just people who for whatever reason can't handle VBR, and there's not much we can do about it.
Whatever encoding program you use is writing the headers incorrectly.
If you need an open source alternative, a quick Google search finds this:
http://mp3diags.sourceforge.net/
It looks like it would probably have that functionality.
http://www.codeproject.com/Articles/8295/MPEG-Audio-Frame-Header#VBRHeaders
Apparently the encoder in Adobe Audition does not write the XING header. If I can find some Linux code or command line app that does it, I can have the server automatically do the VBRfix before it uploads to libsyn.
This one is more complicated, but it has a more thorough validation and fixing process, which might be a good thing for you if it could catch an error before you upload the episode.
Alternatively, if you can switch your encoder over to LAME, I'm pretty sure it would correctly write the XING header; I expect it's also generally better.