[Compatibility report] NW-A918 first sync and playback succeed, but device reports Simple Mode

[MozyOk]

Hi! Thanks for building ManicStage!

I recently picked up a Sony NW-A918 (8 GB) and was very happy to find this project. Since the NW-A900 series is currently listed as Experimental, I wanted to share my test results.

So far, ManicStage seems to work surprisingly well with my NW-A918.

Summary

I tested ManicStage 0.1.5 with a physical Sony Walkman NW-A918.

Device detection, empty-library initialization, one-track import, sync, standard library browsing, and real-device playback all succeeded.

The remaining question is that the NW-A918 reports:

Database: Simple Mode

Standard browsing still works, but Intelligent Shuffle currently exposes only Shuffle All.

I am opening this as a compatibility report and to ask whether Simple Mode is the expected fallback for the A900 series.

Environment

• Device: Sony Walkman NW-A918, 8 GB
• ManicStage: 0.1.5, build 1
• macOS: 26.5.1 (build 25F80)
• Architecture: arm64 / Apple Silicon
• Connection: USB mass storage through a USB hub
• Mount path: /Volumes/WALKMAN
• Filesystem: MS-DOS FAT32 (msdos)
• Reported capacity: 8.1 GB
• ManicStage support level: Compatible Layout
• Initial state: no OMGAUDIO/ or NWWM/ directory

The device itself is functional. One-Seg and video playback work, and a separately prepared compatible H.264/AAC MP4 copied directly to VIDEO/ also plays correctly.

Steps performed

1. Created a complete backup of the Walkman filesystem.
2. Connected the NW-A918 and selected the Walkman root directory in ManicStage.
3. Initialized an empty music library.
4. Imported one test audio track.
5. Ran sync.
6. Confirmed that ManicStage reached 100% and reported sync completion.
7. Checked the resulting library and playback on the physical device.
8. Created another complete filesystem backup for comparison.

Confirmed working

• Device detected by ManicStage
• Device shown as a compatible OMGAUDIO layout
• Empty-library initialization
• One-track import
• Sync completion
• Song count reported as 1
• High-water ID reported as 1
• Real-device audio playback
• All Tracks browsing
• Album browsing
• Artist browsing
• Genre browsing
• Playlist menu is present

Playlist creation itself has not yet been tested.

Device-side result

The Music Library contains:

• All Tracks
• Album
• Artist
• Genre
• Playlist

The device reports:

Database: Simple Mode

Intelligent Shuffle contains only:

• Shuffle All

Therefore, Simple Mode is not preventing basic playback or the standard Album/Artist/Genre browsing categories on this NW-A918.

Filesystem observations

Before ManicStage initialization, the device had no OMGAUDIO/ or NWWM/.

After the first sync, ManicStage had created:

• NWWM/TSTMPTBL.DAT
• 36 non-AppleDouble DAT files under OMGAUDIO/
• One audio payload under OMGAUDIO/10F00/

Examples include:

• 00GTRLST.DAT
• 01TREE*.DAT
• 02TREINF.DAT
• 03GINF*.DAT
• 04CNTINF.DAT
• 05CIDLST.DAT
• RESERVED.DAT
• 10F00/10000001.OMA

With macOS metadata such as ._*, .fseventsd, and .metadata_never_index excluded, all 11 pre-existing files remained byte-identical by SHA-256.

The complete test sequence added 39 payload files:

• 38 ManicStage-related files
• 1 separately tested MP4 under VIDEO/

No pre-existing payload file was removed or modified.

I have reproducible manifests containing file paths, byte sizes, and SHA-256 hashes. I can provide sanitized reports without uploading the .OMA payload, commercial media, or One-Seg data.

Questions

1. Is Simple Mode the expected compatibility behavior for the NW-A900 series in ManicStage 0.1.5?
2. Does ManicStage intentionally omit databases or analysis metadata needed for additional Intelligent Shuffle options?
3. Is Advance Mode likely controlled by a flag/version field, or by the presence of additional tree/group databases?
4. Would sanitized before/after manifests or DAT byte-range reports help investigate A900-series support?

Not tested yet

The following operations have not been verified yet:

• Delete and resync
• Add after delete
• Playlist creation
• Cover art
• Japanese metadata
• Mixed Japanese/ASCII metadata
• Long metadata strings
• Repeated no-op sync
• 10-track library
• 100-track library

I can run these as controlled one-variable experiments and provide before/after reports if that would be useful.

Overall result

For the tested first-sync workflow, the NW-A918 is usable with ManicStage:

• Import: successful
• Sync: successful
• Playback: successful
• Standard browsing: successful
• Database mode: Simple Mode
• Advanced shuffle options: not available beyond Shuffle All

[MozyOk]

Follow-up: controlled testing completed through 100 tracks

I completed the staged tests listed in the original report, except for delete/re-add and playlist creation. The same physical NW-A918 remained usable throughout the experiment.

Updated compatibility result

• No database warning appeared at any tested stage.
• The library progressed through 4, 5, 6, 7, 8, 10, and finally 100 tracks.
• Japanese-only metadata displayed and played without mojibake or loss.
• Mixed Japanese/ASCII metadata, spaces, punctuation, accented Latin characters, and an en dash displayed correctly.
• Multiple artists, albums, and genres were browsable.
• A generated 300×300 attached cover was converted to external 200×200, 96×96, and 32×32 JPEGs and displayed correctly in both browsing and playback views.
• Two subsequent cover-free tracks and all 90 scale tracks displayed no incorrect cover.
• A single 90-track batch reached exactly 100 tracks.
• Scale Probe 001, Scale Probe 045, and Scale Probe 090 displayed exact title/artist/album/genre values and all three played.
• Representative scale artists, albums, Modern, and Study were browsable.
• All ten earlier tracks remained present after the 90-track batch.
• All Tracks had no noticeable slowdown at 100 tracks.

The device still reports:

Database: Simple Mode

Intelligent Shuffle still exposes only:

• Shuffle All

Reaching 100 tracks and allowing the device to rebuild its derived indexes therefore did not change the observed database mode or shuffle options.

Finding 1: long fixed-width metadata is not NUL-terminated

I tested deliberately long ASCII title, artist, album, and genre fields.

• The OMA retains the complete input tags.
• The fixed-width primary database fields store up to 61 UTF-16BE code units in a 122-byte value area.
• A field using all 122 bytes has no 00 00 terminator before the next tag.
• On the playback screen, the complete OMA title remains available.
• In All Tracks, this long track alone scrolls from title into boundary mojibake, then artist, another boundary, and album.
• Shorter zero-padded fields display normally.

One observed boundary is:

... 00 4c 00 4d 54 50 45 31 00 02 ...

UTF-16BE LM is followed immediately by the next TPE1 field tag. This is consistent with the NW-A918 reading until a UTF-16 NUL rather than stopping at the 122-byte value boundary.

Reserving one code unit and limiting the stored value to 60 UTF-16 code units is the leading fix hypothesis. I am not claiming that limit as Sony's formal schema without a reference SonicStage database.

Finding 2: obsolete cover JPEG generations accumulate

The physical cover behavior is correct, but the filesystem accumulates old artwork files:

1. Importing one covered track created six JPEGs: three sizes in each of two database namespaces.
2. Syncing two cover-free tracks generated another six byte-identical JPEGs under new paths.
3. Syncing the 90 cover-free scale tracks generated another six under another pair of paths.
4. At 100 tracks, only the newest paths (20P24 in 03GINF01.DAT and 20P34 in 03GINF2D.DAT) are referenced anywhere in the current DAT files.
5. The 12 older JPEGs remain on disk and are not removed during device use/reconnect.

Record-boundary inspection associates the newest references with the original covered album/artist, not with the cover-free tracks. The original track continues to display its blue cover, and cover-free tracks display none. This looks like cover regeneration/reallocation without cleanup, rather than a user-visible cover leak.

Repeatable ManicStage/device writer boundary

Across seven controlled additions, ManicStage consistently updated the primary writer set:

01TREE01/02/03/04/2D
02TREINF
03GINF01/02/03/04/2D
04CNTINF
05CIDLST

It preserved these five files during host sync:

01TREE0C/0E/0F
03GINF0C/0E

After safe eject, device use, and reconnect, the NW-A918 updated exactly those five files every time, without changing any OMA payload or JPEG.

At 100 tracks:

• 03GINF0C grew from 16 to 56 records.
• 03GINF0E grew from 23 to 65 records.
• The terminal 01TREE0F block contains 100 unique two-byte values whose set is exactly track IDs 1 through 100.
• All 100 OMA files and all 18 JPEGs remained byte-identical across device use/reconnect.

This suggests the NW-A918 successfully consumes the primary ManicStage output and builds these derived browse indexes itself. It does not establish the formal meaning of each suffix or the trigger for Simple Mode.

Test-media and safety note

All added test tracks were locally generated 44.1 kHz stereo MP3 tones. No downloaded or commercial recording was used. A complete USB-root backup was retained, and the comparison tooling never writes to the Walkman.

Still not tested

• Delete and resync
• Add after delete
• Playlist creation
• A true no-op sync, because ManicStage disables Sync when there are zero pending tasks

Updated conclusion

For the tested add/sync workflow, the physical NW-A918 is stable and usable with ManicStage through 100 tracks. The two actionable findings are the missing terminator at the 61-code-unit metadata boundary and accumulation of superseded cover JPEGs. I can open focused issues for either finding if that is preferable.