Try transcoding it at 16/44.1 — I think that’s the highest bitrate supported by S1.

I am unfamiliar with the 16/44.1 format you mention so I'll do some research and attempt to use audacity again or another converter... thx for the suggestion!

It’s the default CD quality - see if this video I just found on YT helps you:

Anything helps!!!!! Again many thx....

Ken..

Using Audacity, I changed the Bit Rate to 16 as Sonos does spec that for S1…. and set to 44.1

Exported as FLAC again, and Unfortunately it still pops the same error message that it is not compatible..

This attempted conversion to 16 Bit / 44.1 (and it before conversion) plays without issue on my Desktop PC using VLC and / Windows Media…  

I’m not getting any errors during the conversion that it can’t complete it or similar.

I welcome any other suggestions anyone might have….

The screenshot is showing the sample-rate as being twice as high as it should be - it needs to be 44,100 Hz - did you re-index your Sonos library after overwriting the track?

Yup…   I re-sampled it numerous times and Updated the Library to insure it was seeing the new file.  It’s as if I did not convert it at all since the same error comes back each time.  I’m stumped…..

Use a different converter, dBpoweramp for instance.

Maybe someone else here, who perhaps uses the audacity software regularly, will chime in and provide a solution for you, or maybe post the issue you’re seeing in their support forum and see if someone there can assist.

You will though need to export the track at a 16/44 bitrate for a Sonos S1 device to play it.

Please let us know if you do find an answer, as it would be nice to know this, just for future reference.

Just a suggestion, you might find that you have to convert it using two separate stages - perhaps try transcoding the track to another format like .wav (16/44) and then go onto convert it back to .flac (if required).

Thanks again for continuing to offer suggestions.…

I also tried an online converter which resulted in the same issue so it's just not audacity.…

How two different (hopefully) files have the same issue is a mystery at this point.. but I will continue to pursue this for a solution...

FWIW converters would effectively do this anyway, with PCM as the intermediate format during the conversion process.

If a converter is not downsampling to 44.1kHz as it’s told to, the converter is broken. Likewise if it’s somehow labelling a correct 44.1kHz conversion as 88.2kHz, it’s also broken.

Creating an intermediate conversion such as wave is something I failed to consider and is a great suggestion! I'll try various codes to see if I can filter out that 88 version…

I'll certainly keep you updated.

...

No need for intermediate conversion. As @ratty mentioned: try dBpoweramp. I’m not familiefar with Audacity but I use dBpoweramp Audio Converter regularly. Easy, efficient and free trial

Well… the saga of the “locked” file continues…

I tried BOTH DB PowerAmp & NCH Switch to convert the “88,200” File

I converted the original file to:

1. FLAC to FLAC
2. FLAC to WAV
3. FLAC to WMA
4. FLAC to WAV to FLAC

All combinations result in the same Error Message of “88,200” not Compatible….

When I hover above the file, I see the following:

At this point my guess is that the original file is weirdly corrupted, preventing its transcoding.

Oh… and all the attempted file transcodings work on my desktop PC using Win Media Player & VLC….

You are removing the original and re-indexing afterwards I assume?

Yes...each and every time....

Give the converted track a new name (tag) from the original to make sure 100% it's the file you're playing.

Thank you ALL for the well thought out suggestions based on what I furnished you….  I finally resolved it and learned something though I’m not sure I can explain it all…

In the SONOS APP, I have the “Music Library” pointed at my Synology 920+ which has a dedicated folder with all my 1600+ Songs. 

When I scroll to the Group, and then the new single song, I was repeatedly met with the dreaded 88,100 Pop UP that it was not compatible. No other file presented this error to my knowledge, though I did not test every song.

As I Updated the Music Library after each file replacement with a new version after countless transcoding's, I saw at the bottom of the SONOS Library list under Artist, Album, etc. a “Folders” option. I opened that and it shows the address link to my NAS. Clicking on it, I’m presented with all the folders in the Music folder. Same Music, just not categorized other than the folder name. Clicking on the Group, then THAT Song…. and it PLAYS!  I went back a few steps to the categories and again clicked on the SAME song and it failed to play and again with the same 88,100 Error.

Going directly into the File Folder on the NAS, I checked the “Recycle Bin and it was empty. I’ve learned in the past that the Recycle Bin, if it contains anything, SONOS will present it as just another file… SONOS doesn’t know it’s a Recycle Bin and ignore it. 

So what was it seeing? Some time ago I learned about the advantage of enacting Synology “Snapshots”  is “a point-in-time copy stored in the same volume used to record the whole data status at the time upon being taken.” I had set it to store the latest 6 Snapshots…. These Snapshots have not been an issue, nor do I need to actively maintain them.. its automatic. But why the issue with this one file? I took a chance and Deleted all 6 Snapshots (60gb+)….  I then clicked on the previously unplayable song… and it worked! I was unaware the Snapshots could even be accessed as its meant to be a secure backup.  

The 88,100 led me to believe it was encoded in a non-SONOS codec… Why it presented that I don’t know. And that original file that never worked is fine and its the one that I am now using.

But it works, and I’ve learned another lesson…

Thanks again….

That was what I suspected, hence the suggestion to rename…. I suspect you were  repeatedly and unknowingly playing the same track.

Or... more than one as it saw 7 different files all with same name...

Effectively the same file though, backed up in different places. When the same file (or different files with the same meta data) exists in multiple locations, from the Library view, it's not easy to see which is being played.  Point remains though, a tag name change would give assurance you're playing the ‘new’ file.

Of course you're completely correct and I'll try to not be let astray By other facts When a similar issue arises!