fix/flac: Actually print relevant incorrect type #49
Conversation
`si` will always be `(*meta.StreamInfo)`, the relevant type is `block.Header.Type` which implements `Stringer`
Co-authored-by: Robin <[email protected]>
|
I agree with your suggestion, it will highlight which data structure was assigned instead of just a static string type. |
|
Hey @karlek @mewmew this reminded me that i should thank you for your flac implementation which was very good to have as an alternative implementation in addition to the xiph one when learning about FLAC. Tack! also wanted to mention that my tool fq has quite good FLAC support partially because of this, it might be handy if need to investigate something FLAC-related. Gott nytt! |
Glad to hear! My brother and I had a lot of fun implementing the Go FLAC library, and it's always fun to hear it has been useful for others :)
Gott nytt! |
Also fell in love with jq some years ago and i also spent a lot of time digging in binary data... then a day one year ago or so i though: what if? :) |
That's awesome! What kind of binary project do you play with? My brother and I also enjoy flipping bits <3 Some assorted reversing projects at: https://github.com/mewrev The most useful of which may be tools/cmd/type2kaitai (and |
Good to hear! hobby and interest-wise it is mostly just to understand how all kinds of things work. At work i do lot of media related things, debug broken files, query and aggregate things about files, verify test things during development etc. That is why there is so many media decoders at the moment :) Also i really like programming languages so working the mix of go/jq has been very interesting, what should be in go, what in jq? how should they interact? also study and help improve gojq has been fun! What sort of stuff are you two up to?
Oj lots of interesting stuff there. Actually just a few days ago I started looking into how to add a kaitai support, been on the todo list for a while. My plan is to do something runtime interpreted to support users providing ksy-files on the command line etc. Good/bad idea? Also PE-decoder is on the wishlist :) |
If you haven't looked at the Kaitai web IDE yet, definitely check it out! You can do live analysis of binary files, and even modify the ksy definitions as you go. Adding some kind of runtime interpreter for ksy-files may be a fun idea at least, if useful, that time will tell ; ) Definitely take inspiration from the Kaitai IDE!
Heh, yeah. Fair warning, |
Yes played around a bit with it, very useful! hope i have time to build something similar for fq at some point. Would be nice to be able to have multiple repl "sessions" and also display decode tree like that or visualize in different ways, have been thinking how to visualize "overlapping" fields somehow, use depth or color blending somehow? To do kaitai at runtime i think i have to more or less implement my own parser/executor somehow. Can't really use the official scala compiler or https://github.com/cugu/kaitaigo as they seem to transpile to go. But i think they will be useful to study.
Sure will! it really helps to have multiple implementations to look at when learning things like this. |
siwill always be(*meta.StreamInfo), the relevant type isblock.Header.Typewhich implementsStringer