2024-06-11 22:57:04 +02:00
Files:-
27 -> This one uses the old format of specifying a variable block strategy. Look into it.
The way to know the blocking strategy for this old format FLACs is to see if min_block_size and max_block_size are different,
if they are, then the blocking strategy is VARIABLE, if not, then it's FIXED.
2024-06-19 04:08:54 +02:00
Playback issues in the example program that may relate to the decoder:-
23 - Crunchy loud noise mixed with the actual audio data
2024-09-25 04:13:37 +02:00
uncommon/02 -> 6 channel audio might be incorrect (not a decoder issue afaik)
2024-06-11 22:57:04 +02:00
uncommon/04 -> We get a bits per sample mismatch
uncommon/10 -> We error with Invalid Signature. I assume for these two I should look for the frame sync bits. But maybe my decoder should reject these. idk.
uncommon/11 -> We error with Invalid Signature
faulty/01 -> This one works when it shouldn't (Wrong max blocksize)
faulty/02 -> This one works when it shouldn't (Wrong max framesize)
Things:-
2025-01-30 01:07:14 +02:00
[ ] Seeking to arbitrary samples
- bufio `Reader` doesn't implement `.Seek` but the underlying `io.Stream` which is just a file DOES implement
`.Seek` so I think bufio `Reader` should have Seeking capabilities too as long as the underlying Reader supports it.
I could hack something together to (dis)prove this.
2024-06-15 01:29:48 +02:00
[ ] Options
2024-06-19 04:08:54 +02:00
- [x] Vorbis comment data
2024-06-15 03:39:53 +02:00
- [ ] Cuesheet ?
- [ ] Seektable ?
- [x] Picture data
2024-06-19 04:08:54 +02:00
[x] File streaming API? io.Stream??
2024-06-11 22:57:04 +02:00
[ ] Lots of checks (look at the TODOs in flac.odin)
2024-06-19 04:08:54 +02:00
[x] Memory optimizations
2024-06-14 00:18:03 +02:00
[ ] Speed optimizations
2025-01-27 23:57:57 +02:00
- Does this matter? So far I haven't found a FLAC file that lags while playing or stalls the audio device even without `-o:speed`
2024-06-11 22:57:04 +02:00
[ ] Seeking
2024-06-15 03:39:53 +02:00
[ ] Fuzzing to test the stability of the code
2024-09-25 04:13:37 +02:00
[x] Check if the use-after-free bug happens on Windows, and if so, if the address sanitizer will show us the full stacktrace
2024-09-24 06:36:33 +02:00
instead of skipping some procs.
2024-09-25 04:13:37 +02:00
This was caused by `read_data()` and the tee reader writing into the buffer and us using some memory that was freed while the buffer
resized. Solution is to use buffer data BEFORE calling `read_data()`
2024-06-11 22:57:04 +02:00
[ ] Encoder (low priority for now)
Security:-
Security concerns will be considered after making the decoder work correctly and robustly.