foo_input_tak, TAK decoder Options

[foosion]

foo_input_tak 0.3.2

Fixed bug with reopening TAK decoder instance after tag update (file position was not reset to start of file).

I've only confirmed that this fixes the problem with tool and evaluation level disappearing from technical information after a tag update, but given the nature of the bug, I expect it was responsible for the rest of the tag updating related problems as well.

Other changes: I made sure to bundle tak_deco_lib.dll 1.0.4 and added a little version information (regarding the TAK library) to the plugin's about message.

This post has been edited by foosion: May 13 2007, 19:13

[yerma]

my problem with silent tracks: FIXED!

Thanks!

[TBeck]

Great!

Thanks for your effort!

Thomas

[GeSomeone]

foo_input_tak 0.3.2
Fixed bug with reopening TAK decoder instance after tag update (file position was not reset to start of file).

Thanks, for looking into this and fixing. Now I dare to tak and tag again.

[Acropolis]

foosion, can you make the embedded cuesheet still editable after adding it?
if by mistake added a wrong timing cuesheet, will be like hell, unless edit it by a hex editor.

[foosion]

Use the "Utils/Edit Cuesheet" command.

[eevan]

I've found the problem with the Secret Rabbit Code Resampler v1.03 DSP plugin and tak. When playing tak file (latest decoding library 1.0.4 and input plugin 0.3.2) foobar 0.9.4.3 doesn't crash, but the output is silent and the time cursor is moving faster than usual. Spectral analyser is active as well. I've tried the other resampler plugins and everything worked ok.

[Acropolis]

Use the "Utils/Edit Cuesheet" command.

I didn't know that, thanks

[IrfCore]

I noticed a small issue in foobar with TAK Decoder 0.3.2 beta.
In Windows Explorer when you right click on more than 1 file(s) and choose Play in foobar2000 it doesn't work.
But it works when you right click on the folder or just 1 file and choose Play in foobar2000.

Edit:
It isn't a bug.
Something is wrong in my windows installation...
When I reinstall, I will check if it is the same, probably not.

This post has been edited by IrfCore: Jul 1 2007, 03:29

[musicmusic]

BTW foosion, slight OT but I was using application verifier today, and it is whinging about something coming from tak_deco_lib.dll on foobar2000 shutdown (reproducible). Something you may wish to look into.

[edit] This is the message:

CODE

=======================================
VERIFIER STOP 0000060A : pid 0x14DC: Incorrect FreeType parameter for VirtualFree operation.

    0000C000 : Incorrect value used by the application.
    00004000 : Expected correct value 1.
    00008000 : Expected correct value 2.
    00000000 : Not used.


=======================================

As you can see on msdn someone has incorrectly combined the two flags.

Call stack (with app verifier running):

CODE

    vfbasics.dll!AVrfpVirtualFree(void * lpAddress=0x05270000, unsigned long dwSize=0x00000000, unsigned long dwFreeType=0x0000c000)  Line 1484 + 0xf bytes    C
    tak_deco_lib.dll!05bba472()     
    tak_deco_lib.dll!05ba3353()     
    tak_deco_lib.dll!05bba7f7()     
    tak_deco_lib.dll!05ba3d64()     
    tak_deco_lib.dll!05ba4076()     
    tak_deco_lib.dll!05ba6401()     
    tak_deco_lib.dll!05bc5c18()     
    verifier.dll!71ac5999()     
    vrfcore.dll!VfCoreStandardDllEntryPointRoutine(void * DllHandle=0x05ba0000, unsigned long Reason=0x00000000, _CONTEXT * Context=0x00000001)  Line 557 + 0xc bytes    C++
    vfbasics.dll!AVrfpStandardDllEntryPointRoutine(void * DllHandle=0x05ba0000, unsigned long Reason=0x00000000, _CONTEXT * Context=0x00000001)  Line 705 + 0x14 bytes    C
    ntdll.dll!773ea604()     
    ntdll.dll!773ba303()     
    verifier.dll!71ac73b2()     
    ntdll.dll!773ba2e2()     
    ntdll.dll!773ba38e()     
    kernel32.dll!772dd873()     
    vfbasics.dll!AVrfpExitProcess(unsigned int uExitCode=0x0012ff04)  Line 205    C
    kernel32.dll!772dd85e()     
    foobar2000.exe!0049711c()     
    foobar2000.exe!00497336()     
    foobar2000.exe!0049735b()     
    foobar2000.exe!00496813()     
    kernel32.dll!772e3833()     
    ntdll.dll!773ba9bd()

Bye

This post has been edited by musicmusic: Oct 4 2007, 16:04

[foosion]

BTW foosion, slight OT but I was using application verifier today, and it is whinging about something coming from tak_deco_lib.dll on foobar2000 shutdown (reproducible). Something you may wish to look into.

I moved the post; it is slightly less OT here. Anyway, this seems to be an issue with tak_deco_lib.dll itself which is provided by TBeck. I don't now whether this might be coming from the Delphi runtime, or if he has his own memory management functions. I'll send him a link to your post so he can check.

[musicmusic]

I moved the post; it is slightly less OT here.

Thanks, I was too lazy to find a better place

I don't now whether this might be coming from the Delphi runtime

I hope not

I didn't do anything else with the TAK component (like decode files..) so I don't know if it triggers elsewhere.

[foosion]

I've tested takc.exe with the application verifier, and I get exactly the same message. The plot thickens.

Edit: takc.exe was run without arguments.

This post has been edited by foosion: Oct 4 2007, 18:21

[TBeck]

BTW foosion, slight OT but I was using application verifier today, and it is whinging about something coming from tak_deco_lib.dll on foobar2000 shutdown (reproducible). Something you may wish to look into.

[edit] This is the message:

CODE

=======================================
VERIFIER STOP 0000060A : pid 0x14DC: Incorrect FreeType parameter for VirtualFree operation.

    0000C000 : Incorrect value used by the application.
    00004000 : Expected correct value 1.
    00008000 : Expected correct value 2.
    00000000 : Not used.


=======================================

As you can see on msdn someone has incorrectly combined the two flags.
...

Thank you!

...
I moved the post; it is slightly less OT here. Anyway, this seems to be an issue with tak_deco_lib.dll itself which is provided by TBeck. I don't now whether this might be coming from the Delphi runtime, or if he has his own memory management functions. I'll send him a link to your post so he can check.

And thanks to you too!

No, it wasn't Delphi. For some strange reason i have combined the flags MEM_DECOMMIT and MEM_RELEASE . I will correct this in TAK 1.0.2.

Again: Thank you very much!

Thomas

[musicmusic]

Thank you!

No problem I only found it by chance..

[Squeller]

Hi foosion, AFAIR you wanted to do some decoding performance tunings; any news on the issue?

[foosion]

No, my only idea was to always decode one frame at a time. However, that already happens when dynamic bitrate reporting is disabled, and it does not seem to affect the overall decoding speed.

[foosion]

foo_input_tak 0.3.4

Recompiled with latest TAK SDK. Added recognition of "insane" profile introduced in TAK 1.0.2; profiles of unrecognized (i.e. future) TAK versions are displayed numerically. Bundled tak_deco_lib.dll 1.0.5. Added options in Advanced preferences to restrict CPU optimizations tak_deco_lib may use.

[Spirit_of_the_oc...]

Thanks a lot

[Audio_Adepta]

Im not sure if this is a problem specifically with the foobar tak plugin, or with all input plugins that use embedded cue sheets; but I have noticed that when loading a cue sheet directly into foobar with the line
"REM DISC 2"
it will respect this command when displaying the information in foobar - whereas if I copy this cue sheet and embed it in the same file, it looses this line in the cue sheet but retains it separately as a tag. I know that this is nitpicking at the features but I just dont understand why it cant retain this information in the embedded cue sheet when it retains things like catalog numbers and such.

[eevan]

It retains only standard fields.
This is a user comment which maps to DISC tag, so that's the way it is handled.
Take a look at cuesheet specs

[alvaro84]

Hm, I just tried to search for this thing in this topic, but without success

So, I embedded a cover jpeg inside a .tak file today, and according to mp3tag it's there, though my foobar doesn't show it (now I'm using 0.9.5.1 default UI and it works properly with album art embedded into mp3 and flac files). My question is that where is the problem? In mp3tag, in foo_input_tak, or in the tak format specs? If it's foo_input_tak, is there a version under development which will show the embedded art?

A second question: according to the discussions with TBeck it seems that something in foobar significantly decreases tak decoding speed, in stand-alone decoders it's almost on-par with flac. Not that it's a deadly problem, tak is plenty fast already, but I'm curious if it's some foobar architectural limitation, or some interfacing problem between foobar and the external tak decoding library?

Sorry if anything... no offense meant, of course, foo_input_tak is a very useful component that works well anyway

[foosion]

So, I embedded a cover jpeg inside a .tak file today, and according to mp3tag it's there, though my foobar doesn't show it (now I'm using 0.9.5.1 default UI and it works properly with album art embedded into mp3 and flac files). My question is that where is the problem? In mp3tag, in foo_input_tak, or in the tak format specs? If it's foo_input_tak, is there a version under development which will show the embedded art?

The current version of foo_input_tak predates 0.9.5 and does not contain functionality to access embedded cover art.

A second question: according to the discussions with TBeck it seems that something in foobar significantly decreases tak decoding speed, in stand-alone decoders it's almost on-par with flac. Not that it's a deadly problem, tak is plenty fast already, but I'm curious if it's some foobar architectural limitation, or some interfacing problem between foobar and the external tak decoding library?

I don't know what is causing the decreased decoding performance. Considering that the plugin works and that performance isn't abysmal, I however have very little motivation to investigate this further. I can provide the source code, if someone else wants to.

[alvaro84]

Thanks for the answers - the performance isn't 'abysmal', TAK still looks the second fastest lossless codec and its speed is on par with mp3 so I don't think it could cause any problem on virtually any config that can run foobar itself.

[foosion]

foo_input_tak 0.4

Adds the ability to read embedded album art. Requires foobar2000 0.9.5.