atracdenc/src, branch fix_input_file_path

Drop FileModeToWide allow-list

2026-05-03T18:47:07Z

Widen the ASCII fopen mode string with std::wstring's iterator-pair constructor instead of maintaining a hand-coded mapping. ASCII (0-127) codepoints are valid wchar_t code units on Windows, which is the only alphabet fopen modes use. Co-Authored-By: Claude Opus 4.7

Clean up UTF-8 path handling

2026-05-03T18:37:20Z

Reuse the shared UTF-8 path helper in Media Foundation, normalize compressed output open errors, cover AEA encode/decode paths, and expand integration tests for ATRAC1 and decode filenames.

Fix UTF-8 input and output paths

2026-05-03T18:20:31Z

Report libsndfile open failures before sample-rate validation, use UTF-16 Windows opens for PCM and compressed containers, and add integration tests for missing input plus UTF-8 input/output filenames.

Add MSYS2 build support (#70)

2026-05-03T12:41:21Z

* Add MSYS2 build support Add a selectable PCM I/O backend so MSVC builds can keep Media Foundation while MSYS2/MinGW builds use libsndfile. Teach the libsndfile finder about MINGW_PREFIX and add a Windows MSYS2 CI job that builds the libsndfile backend. Fix and enable tests for MSYS2 builds

Fix mono AT3 RIFF channel count. issues/67

2026-05-02T21:42:38Z

AT3 RIFF output always stores a two-channel ATRAC3 stream. Mono input is encoded as duplicated single channels or as joint stereo with an empty side channel.

Initialize bit allocator LastLambda during the start allocation. Fix issues/69

2026-05-02T20:34:24Z

Merge pull request #66 from dcherednik/new_psy

2026-04-19T22:49:22Z

Conservative initial implementation of ATRAC3 tonal extraction. This is a safe first step tuned for stability and bitstream compatibility, not maximum aggressiveness. It gives the most benefit on synthetic signals and material with strong, steady pure tones (for example simple electronic leads and solo tonal instruments).

atrac3: reimplement tonal encoding. Use flatness-based tonal extraction

2026-04-19T22:27:45Z

- Add shared CalcSpectralFlatnessPerBfu helper in atrac_psy_common with BFU-table mapping. - Implement ATRAC3 tonal extraction: compute MDCT energy, estimate per-BFU flatness, extract up to 5-bin strongest tonal run in low-flatness BFUs, and zero extracted bins in residual. - Map extracted tonal bins into TTonalBlocks and integrate them into bitstream coding. - Update ATRAC3 bit allocation - reduce residual bits for BFUs with tonal blocks, and increase tonal quantizer selection. - Restore --notonal CLI option in main.cpp for A/B comparison.

at3: write fact chunk, fix bytes_per_frame and chunk sizes

2026-04-16T23:20:59Z

The AT3-in-WAV writer produces headers that Sony's psp_at3tool rejects for files longer than around forty seconds. The tool prints "input file is illegal file or over 2G Byte" and refuses to decode. ffmpeg accepts the file but decodes it without any encoder-delay compensation, leaving a variable lag of several hundred samples relative to the source. The two observations have a common root cause: the header we write is missing fields that downstream decoders rely on. This patch addresses three concrete issues in src/at3.cpp. First, the writer emits no fact chunk. The fact chunk is optional in the general RIFF specification but is how WAVEFORMATEX based codecs announce the total number of decoded samples per channel. psp_at3tool uses the sample count together with samples-per-frame to decide how much PCM to produce and where to stop. Without a fact chunk the tool falls back to a short default and either truncates output or, for longer streams, rejects the file outright. ffmpeg uses the same field to skip encoder priming samples. Sony's own AT3 files carry this chunk with a fixed eight byte payload containing total_samples and samples_per_frame. We now write the same structure. Second, the bytes_per_frame field in the ATRAC3 extradata was hardcoded to 0x10 with an XXX comment. The correct value for standard ATRAC3 is 0x1000, that is 4096, which corresponds to the PCM bytes represented by one frame (1024 samples per channel times two channels times two bytes per sample). Sony's encoder writes 4096 at this offset and both ffmpeg and psp_at3tool validate against that number. The previous value of sixteen bytes per frame is nonsensical and was part of why psp_at3tool misestimated the playback length. Third, the RIFF chunk_size field was being written as the full file size. By the RIFF specification this field should hold the size of everything that follows the field itself, that is file_size minus eight. Writing the full size is tolerated by ffmpeg but violates the specification and makes the file look larger than it is to strict parsers. Because the PCM engine can flush additional frames after the initially estimated numFrames count (due to look-ahead tail during encoding), the three length fields chunk_size, total_samples, and subchunk2_size were stale by one to three frames relative to the actual data on disk. To keep them consistent, TAt3 now counts frames as WriteFrame is called and seeks back to overwrite the three length fields in the destructor, so the final file describes its real contents. The patch is purely a container metadata fix. The encoded AT3 payload is byte-identical to before. After this change, output from atracdenc for long test tracks (90 and 186 seconds, 132 kbps LP2) is accepted and fully decoded by psp_at3tool in a single pass, and ffmpeg decodes with a constant small codec latency instead of the previous variable drift. This made it possible to run a proper triple comparison against Sony's reference encoder, which previously looked catastrophic (gap around -22 dB SNR) purely due to the alignment problem but sits at roughly -0.5 to -1.4 dB SNR once the container headers are correct. Signed-off-by: hilman2

[AT3] refactor bitstream allocation loop to bs_encode

2026-04-11T21:20:06Z