I just happened to notice in the past day that all files I have edited with Yate in past what it appears to be two versions (For sure latest version) are changing writing out something different than what I see in the editor.

I have set my multi-item delimited as "; " (ignore quotes). I use this in two fields - artist and composer. Yate for years has written that to files exactly how I see it in the editor.

I now noticed Yate is replacing with two backslashes and I can't figure out what changed or how to get it back to the way it was? I may also need a script to search for these as now paranoid about how many files might have gotten changed in my 120K+ library.

Kind regards

Just emailed preferences. Have seen this occur in FLAC, DSF, and Apple Lossless. Still trying to determine the exact pattern and repeatability.

To answer your question what I noticed is on my digital music transport the latest albums show a "|" between multiple artists where normally it is artist a; artist b. I then looked at the files in my on computer library (Swinsian) and it shows these artists with a space between. MP3 tag shows the \\ between the artists. If I hand edit them out with either of those programs they will be corrected. Oddly Yate shows them the same regardless of \\ or ; - always shows them as ; .

I can open files add a second artist in Yate and save and verify it writes them out with \\. Been using Yate for years so must have mistakenly set something that is causing the issue.

I should add the other software products may be showing things differently might be able to rule that out but definitely seeing differences on the downstream music transport which is the most important part of the chain for me.

Thanks for quick reply doing some more debugging/trial/error to try to get a repeatable pattern. The double slashes were being shown my MP3tag which I rarely ever use and discovered that is the default for a delimiter in that program. Will be back in touch shortly

So here's the results. The good files were not last edited by Yate or the multi-item delimiter was not <semi colon><space> when they were written. The multi item delimiter is being written to the files as opposed to it being encoded properly for the ID3 specification. (Used by DSF files)

Example: Skylark.dsf (in the good dump)

00000028 00000082 00000054 (0000T3) TPE1
627220600: 54 50 45 31 00 00 00 2c 00 00 03 43 61 73 73 61 6e 64 72 61 |TPE1...,...Cassandra|
627220620: 20 57 69 6c 73 6f 6e 3b 20 4a 69 6d 20 44 65 61 6e 67 65 6c | Wilson; Jim Deangel|
627220640: 69 73 3b 20 54 6f 6e 79 20 53 69 67 6e 61 |is; Tony Signa |

TEP1 is the artist tag in ID3. Notice that the <semi-colon><space> text is in the data. This is blatantly incorrect. In ID3v2.4 multiple items are separated by a binary 0.

Example: Skylark.dsf (in the bad dump)

00000028 00000069 00000041 (0000T3) TPE1
627220600: 54 50 45 31 00 00 00 1f 00 00 03 43 61 73 73 61 6e 64 72 61 |TPE1.......Cassandra|
627220620: 20 57 69 6c 73 6f 6e 00 4a 69 6d 20 44 65 61 6e 67 65 6c 69 | Wilson.Jim Deangeli|
627220640: 73 |s |

This version, written by Yate with a <semi colon><space> delimiter is correctly formed. Notice the binary 0 between Wilson and Jim

As Yate has been encoding multi-item ID3v2.4 fields exactly the same since 2012, I can only surmise that the so called good files were not tagged with Yate ... or the Multi-Item delimiter was not <semi colon><space> when the files were written.

If the 'good' files are displaying properly on your streamer, it is implicitly looking for a semi-colon. If the 'bad' files are not being displayed correctly, the streamer is not properly decoding ID3v2.4 data. The spec has been around for about 20 years now.