@Eric Just touching base on any progress on this issue. We left it with the evidence that Roon windows would import all these odd files (funny bitrates, mp3 2.5, etc.) but label them corrupt (although play) but that Roon linux (SonicTransporter) wouldn’t import these files at all (shows them as skipped). You noted that they would address this when looking at codecs later and I’m just checking to see that this is still on someone’s list. Thanks.
Hi @garym — It’s good to hear from you, and again, thank you for your patience here. I see the ticket is still with my devs and when I meet with my team today I am going to put in an update request.
-Eric
Thanks. No big hurry on this as it is obviously a fairly minor point.
A bit of new information on this topic that may be useful. Not sure which version this happened in, but as of build 233 I’ve noticed the following:
-
In linux (sonictransporter i5, with attached exfat USB drive) nothing has changed. Same type of files remain labeled as “corrupt” and do NOT import.
-
Something new: In windows 8.1 PC version of roon server, the files formally labeled as CORRUPT no longer show up as corrupt after a “re-analysis”. Recall in windows these files were always imported, but they were labeled corrupt, although roon would play them just fine (as opposed to linux above where they are not imported and show as “skipped” files upon import).
Just trying to eliminate the basics… MP3 issues are usually a result of codecs not being installed properly on ROCK
@garym have you done that?
I have many thousands of mp3 files that import and play just fine in Roon. As noted in more detail in my other posts that I refer to, the mp3 files that won’t import (in linux) or that used to be marked as corrupt (in windows Roon) are all strange in some way. They are odd sample rates, mp3 2.5, etc. (mostly from older podcast files). Your team has examples of some of the various types of odd mp3 files that won’t import.
edit: For example:
A file created with MPEG 2.5 Layer III, that has a sample rate of 11025.
a file created with MPEG 2 Layer III, that has a sample rate of 22050ah ok… got it. ignore me 
Never. I hang on your every word (really). 
Any updates on this issue. All facts are still the same. certain odd mp3 files import and play just fine in Roon on my windows machine, but show as skipped/corrupt in my linux version. You guys have examples of some of the actual files. Thanks.
Hey @garym – one thing to keep in mind is that Roon depends on external decoders for MP3 and AAC files – these are the codecs that ship with Windows and OSX, or the codecs you install yourself on Linux. Some platforms are going to be more permissive of non-standard or broken files than others, so just because it worked on one doesn’t mean it’s a bug if it fails somewhere else.
The real question is whether the files are actually broken or not. I just ran one of the MP3s you sent over through MP3Val and it is reporting some errors with the file:
Analyzing file "C:\Users\Mike\Downloads\dick_cavett_show.mp3"...
WARNING: "C:\Users\Mike\Downloads\dick_cavett_show.mp3" (offset 0x1ad104): It seems that file is truncated or there is garbage at the end of the file
WARNING: "C:\Users\Mike\Downloads\dick_cavett_show.mp3": Wrong number of MPEG frames specified in Xing header (16639 instead of 16641)
WARNING: "C:\Users\Mike\Downloads\dick_cavett_show.mp3": Wrong number of MPEG data bytes specified in Xing header (1730456 instead of 1730768)
INFO: "C:\Users\Mike\Downloads\dick_cavett_show.mp3": 16641 MPEG frames (MPEG 2 Layer III), +ID3v2, Xing header
Done!
I will double check with our team about this file to see if we can get a better sense of whether there’s more to be done here, but I did want to be clear that handling of broken files will vary from platform to platform, and there are times when these distinctions are beyond our control. I’ll let you know if we think there’s anything else we can do to get this working on Linux.
Also, note that he errors I mentioned above can generally be resolved by re-encoding the file.
Thanks. I fully understand. (the odd thing to me is that linux doesn’t like something that windows is OK with. I tend to think of windows as being more picky). All these files are old podcasts or odd ball files that are not critical at all from an audio quality point of view. Only reason I care is that I like to check that my file totals are the same across various systems. I’ll probably just re-encode all these to mp3 sometime and see if they will import.
Sounds good Gary – appreciate your patience on this!