Computing desk
< January 11	<< Dec \| January \| Feb >>	Current desk >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

January 12

Sliding DFT implementation in foobar2000?

RESOLVED

Although there are no replies on this discussion (therefore it is stale), I've added caveats section to the relevant article. Any further discussions (especially regarding the units used in absolute playback time and p_offsets in foobar2000's visualization streams) should be posted at either Hydrogenaudio forums, r/foobar2000 subreddit or any other venues related to foobar2000. (non-admin closure) 2001:448A:304B:1D83:C9D7:338D:5AB9:C88A (talk) 18:33, 13 January 2023 (UTC) (actually, my IP was changed from what I posted this)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Unlike Goertzel algorithm (which is admirably slow for full spectrum calculations on arbitrary frequency scale) that I use for constant-Q transform visualizations on my sketch, the sliding DFT do require contiguous streams of data since it only feeds on new data (which makes it faster since you don't need resetting the coefficients after its done). However, the current visualization stream might not allow easy implementation of this (but it doesn't mean sliding DFT is impossible in foobar because it has offsets and it can set p_requested_length to anything to cover the new data and omit ones that are already covered by previous calculations if done correctly), and since both p_requested_length and p_offset are in double-precision floating point format, I wonder these two are in samples (which is always an integer), or in milliseconds (which requires conversion from samples to milliseconds and vice versa)? 2001:448A:304B:1D83:D4C7:3183:23D5:C02F (talk) 20:01, 11 January 2023 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

"Link compatibility"

I'd like some help rewriting the short section at MinGW#Link_compatibility, because I don't fully understand it.

Binaries (executables or DLLs) generated with different C++ compilers (like MinGW and Visual Studio) are in general not link compatible. However, compiled C code is link compatible.

We don't have an article on link compatibility, it's not mentioned elsewhere in the article and the section doesn't define it.
I think it's saying that a C++ application made with one compiler might not link to a dll compiled with another.
Based on the source, this is something to do with name mangling and the application binary interface?
However, compiled C code is link compatible - I think this means "if the DLL is written in C", as the source says.

I think the second sentence is talking about applications written in C++ being linked to DLLs written in C, which isn't made clear since it doesn't actually say "DLL" or "C++". But as the source says, This issue is not specific to MinGW, so I don't know if it even belongs in the article. Card Zero (talk) 14:17, 12 January 2023 (UTC)[reply]