Question

Additional bytes in Foobar playlist

  • 21 October 2020
  • 4 replies
  • 178 views

When creating a playlist file in foobar2000, the characters in the tracks prompt me to use m3u8 instead of m3u. m3u files work OK on Sonos, but m3u8 files have four bytes at the start of the file that throws Sonos, which says that it can’t play the file. This error comes up at the start and then it goes on to play the remainder of the files properly.

The bytes are  EF BB BF 23 - if deleted using a hex editor then the files play OK.

It seems perfectly reasonable that Sonos should ignore garbage, but does anyone know which software is at fault? i.e. should Sonos play m3u8 files properly, or is Foobar200 not creating them properly?


This topic has been closed for further comments. You can use the search bar to find a similar topic, or create a new one by clicking Create Topic at the top of the page.

4 replies

It sounds like a Byte Order Mark. See if you can disable it. 

That said, I’m not entirely sure that Sonos claims to support M3U8...

It sounds like a Byte Order Mark. See if you can disable it. 

That said, I’m not entirely sure that Sonos claims to support M3U8...

Thanks for the info.. I’m not sure about M3U8 either but it looks like a number of my tracks have unusual characters in them - mainly based on non-English track titles.

I’ve had lots of issues around non standard characters, too (Gaelic). I’ve always attributed it, with zero justification, to the limitation of the Linux kernel that runs on the speakers, under the assumption that it doesn’t handle an extended character set. Am somewhat hoping that the next large number software release [13.0? I don’t expect that huge a change in a dot release, i.e any 12.x version...] would include a new kernel, which I hope includes updates to SMB v1 and an extended character set…

But I’m not an expert on all this, it’s merely guesses on my part. There are folks with much more technical knowledge than I on these forums. 

I’ve had lots of issues around non standard characters, too (Gaelic). I’ve always attributed it, with zero justification, to the limitation of the Linux kernel that runs on the speakers, under the assumption that it doesn’t handle an extended character set.

I’d always assumed that Sonos handled extended character sets properly, as they’re coded for many languages and I’ve never noticed a problem with these exact same files playing under the Sonos software - doesn’t mean that there wasn’t one, though.

I’m not affected by new versions of the software, as I’m locked down at 10.4. However, simply chopping out the offending bytes appears to work on the couple of playlists that I’ve tried so far - and I wasn’t planning on using many of them, just enough to get some headroom on the main Sonos dataset.

At the end of the day, if I can’t get this to work properly it;s not the end of the world - the casting approach works fine on the full dataset, apart from (I suspect) a heavier drain on my phone batttery.