in_zip (v0.6.8.5 29/10/2006)

[DrO]

in_zip v0.6.1.0 'Mouser X Edition'

• Added in a preferences dialog for allowing the association of archives/files with the plugin (if the code doesn't detect the right header in the files associated then they aren't going to play) *
• Enabled preferences option for the ability to remove the root archive entry once played (saves the manual editing as 0.6.0.0 required
• Adjusted the alt+3 dialog handling so that it now won't reset the title when used on the non currently playing tracks (handling for the currently playing item is still a bit iffy)
• Removed the alpha status since it's now in a stable state as far as i'm concerned (just don't play archives with archives in them )

get v0.6.1.0

* This will only control what's added to Winamp's file type list (and any other file dialogs like the add file(s) dialog in the playlist editor. This will not disable support for different archive formats eg removing 7z won't disable 7z handling of manually added files (if that all makes sense, heh)

-daz

[DrO]

in_zip v0.6.1.2

• Fixed a potential crash issue with incorrectly formed input plugins when in_zip is enumerating the supported types
• Added in a few extra checks to better handle some aspects of in_* plugins not being set (unlikely to be from normal plugins but showed up when developing with another in_* plugin which hadn't been fully formed)
• Improved exit handling when the config or about dialogs are open so that it won't crash Winamp if they were open at the time of exiting

get v0.6.1.2

Quick fix build to fix a few issues that showed up when i was messing around with trying to make a in_cd_text plugin. This is likely to be the last build for a while again (due to holiday and i've got a few other projects queued up for working on during my lunch breaks at work since all evening work is now designated for another project once i get back off holiday)

oh and the 0.6.0.0 changelog is up now on my releases page so if you're interested you can see what i did for that build (lots of changes/work was done on it due to people wanting unicode support in winamp - what a silly thing to want )

-daz

[Maxim]

I tried making a custom extension "vgmrar" to allow association without corrupting archive handling (if that makes sense); but the plugin seems to only be able to handle files with regular extensions. Since all(?) the formats supported have identifying "magic" bytes at the start of the file it should be relatively easy to figure out the format of a file with an unknown extension.

Also, I'd still like to see it order the files using a playlist found in the archive (and put any extra files found at the end of the list).

[DrO]

doh, looks like i missed out some of the code for the config dialog to match back to the isourfile(..) function checks. i'll get it sorted out tonight. and yes, the code in there is already using the magic bytes to identify the different files so a rar renamed to zip should still work correctly but good find on my sloppy coding (is almost good to know it's not just myself, mouser x and mclane using the plugin)

yeah, i need to do extraction based on a playlist in the archive, it's just the old issue of trying to find the time to get things done with everything else (i miss the days of working part time when i had loads of time to code )

-daz

[billyvnilly]

I'm sure if you spam the plugin on torrent and edonkey forums, people would start using it.

those are the only kind of zipped music files i have. Always look on the bright side, at least YOU are getting use out of your plugin, adios.

[Mclane]

Originally posted by DrO
is almost good to know it's not just myself, mouser x and mclane using the plugin
daz

"if you make it, they will come!!!"

Or some other such Kevin Costner baseball movie quote

[DrO]

heh, that's a dire but amusing comment mclane

billy, yeah that is one way though i've always felt uncomfortable about spamming my work at people though if i can get the playlist thing and some decent prefs for the rules editor done then i'd get it up on winamp.com which would help things i think just to invent that time duplication machine heh

-daz

[Koopa]

is almost good to know it's not just myself, mouser x and mclane using the plugin

Me too, but still no time for testing and start bugging you.

[DrO]

heh, with the work that mouser did for the pre and full 0.6 builds there shouldn't be too many issues with things it's just a lack of features and the incomplete code maxim's found that i know off

-daz

[Red Mullet]

Works good: http://www.nunzioweb.com/daz/files/in_zip_v0_5_0.exe thanks DrO

[DrO]

what?? 0.5.0 does not work well, is extremely buggy and should never be used.

-daz

[DrO]

i've got some test code in place on my box at work which will allow the isourfile/isourfileW(..) functions to work correctly against the specified extension list though it is parsed last after the default associations have been processed since i want the plugin to handle it's known formats whatever the case when the plugin is installed and no extension list is specified. just need to merge this into the plugin tonight (due to a few other things dev time disappeared last night) and check that it's working correctly (currently been using vgmrar as a working example so hopefully it should all be fine). so here's hoping 0.6.1.3 will sort out the issue maxim reported..

-daz

[DrO]

in_zip v0.6.1.3

• Implemented handling of the plugin's associated extension list to be used to add to the files which the plugin will attempt to handle (was only handling the built-in defaults before so vgmrar should work now )
• Fixed the handling of different extensions (found due to the above change) so that it now isn't fixed to 3 character extensions for some internal handling

get v0.6.1.3

Let me know how this one goes - was testing with vgmrar as an example file extension and it worked for me.

-daz

[DrO]

in_zip v0.6.1.4

• Fixed in_zip to work correctly when JTFE queues a zip:// entry or any queries on zip:// entries related to the IPC_GETPLAYLISTFILE api

get v0.6.1.4

Thanks to mouser x once again for the bug report and helping to work on the fix (considering i'm half asleep at the moment that wasn't easy, heh)

-daz

[Koopa]

SNESAmp sometimes play the .rsn files sometimes not, so I decided to rename the files to .rar and use in_zip to play them. But I noticed, that in_zip just show the path to the temp folder instead of the Tags.

With all other formats in_zip works fine (gym, usf, psf), but with .spc files not.

[DrO]

that's strange and yeah i see what you mean about the titles not working correctly since with the test rar (which was rsn) i've got i just see 'smw-01.spc' for example. i'll have a quick look into what's going on now with things (wonder if it's ever worked for rar'd spc files or some of the recent changes broke things)

[edit]
in fact it's rather hit and miss on handling of the title it seems so i'm not too sure what's going on - probably something simple like normal though i bet, heh

-daz

[DrO]

in_zip v0.6.2.0

• Updated code to use correct unicode apis on 5.25 installs (now they're there for final)
• Fixed an inconsistancy in the ansi code where it incorrectly stored the currently playing zip:// entry minus the ,X part - caused titles, etc to fail such as with *.spc files
• Few minor code cleanups to keep code size down

get v0.6.2.0

Give this build a go koopa - seems to work correctly on my 5.24 and 5.25 installs now (was working inconsistantly on both setups) and also found a nasty bug on pre 5.25 installs.

-daz

[Mouser X]

I've had Winamp up and running since before you (officially) released 0.6.1.4, so I haven't installed 0.6.2.0 until just a few minutes ago. However, I've had a really nasty thing happen a few times, where my PC pretty much locks up nearly completely. Everytime this has happened, it happened during an extraction process, so between songs playing. The problem is, that everytime this problem has happened, I'd been playing from ZIPs or RARs, or something (probably ZIPs, in this specific case) for probably close to 24 hours. Since I just barely installed in_zip 0.6.2.0, it'll take me a bit of time to confirm whether or not this possible bug is still present. And, since I'm leaving for a trip very early Thursday morning, I may not be able to do that, since I might not have Winamp open and playing long enough...

Anyway, I just thought I should let you know that this issue might exist, since it's happened to me a few different times, while Winamp was extracting songs. Hopefully, it was inadvertantly fixed in the newest version (or, that it was just something really screwed up on my end, and simply doesn't happen again). Since I might not have the chance to try to trigger this again until Monday, or Tuesday (I don't get back until Saturday, and chances are that I won't have Winamp running long enough until Monday, since I'd have to have it playing through Sunday), I thought you'd like to know about it, to see if you can somehow set it off (if it even exists). If it exists, I guess I've never run into it before, because I haven't been playing from ZIPs long enough to trigger it... I've recently been listening through my USF collection from hcs64.com. It's a rather large collection.

Anyway, hopefully this is no longer an issue. But if it is, hopefully you can duplicate, and fix, it. Mouser X over and out.

[Koopa]

Give this build a go koopa - seems to work correctly on my 5.24 and 5.25 installs no

I'm sorry, but it still doesn't work on my system.

Tried .spc files in Zip, Rar and 7z archives, everytime the same result. It shows just the file name, when I start playing a file it shows the path to the temp folder instead of the tag. Playing uncompressed .spc files works fine (Tags are shown)

Using 5.25 latest beta, SNESAmp 3.2 and in_zip 0.6.2.0. I can provide more infos about my system and make screenshots if you want.

[DrO]

hmm, something is messing up then since it worked correctly on my main 5.24 and test 5.25 install *shrugs* i'm not too sure then what's going on though i did have one quirk with 5.25 where it was generating the title correctly but it never seemed to be used by winamp and now you've said it's not working on any count i have a horrible feeling it's to do with that. can you try it on an older version of winamp like 5.24 please

-daz

[Koopa]

can you try it on an older version of winamp like 5.24 please

Of course.

[Koopa]

It works with Winamp 5.24, it shows the file name, when I start to play a file, it shows the tag correctly. (.spc works different then other formats, the root entry for other file types like .usf shows the tag before start playing, when I'm not wrong?)

You're right it's related to 5.25. Winamp 5.24 works for me.

[DrO]

damn, i'm guessing if i can work out what's going on with that weird root entry for one of my zips i bet that'll be the solution to your 5.25 issue. oh well at least it shows that the fixes for 5.24 and earlier worked, heh

it should just show the filename when displayed and it's only on playback will the tag be displayed (still need to look into some sort of quick way display the tags from archives without having to use my psuedo-tags in the zip's comment field.

-daz

[Koopa]

it should just show the filename when displayed and it's only on playback will the tag be displayed

When I got you right, then the plug-in works fine with 5.24. Before playing a file it shows the file name, when start playing it shows the tag.

With 5.25 it shows the file name before playing and when start playing a file it shows the path to the temp folder instead of the tag.

Just to be clear. Sorry when my description in previous postings was maybe a little bit confusing.

[DrO]

can you just see if it's only with *.spc that the issue happens or if any other file formats are affected in 0.6.2.0 please (just need a sanity check to make nothing else isn't working right)

-daz

[Koopa]

It was just related to .spc files, with all other files I had no problems, the tags were shown (Winamp 5.25 Beta and in_zip 0.6.1.4)

Now I should test, if the issue, that the path to the temp folder is shown instead of the tag is reproducible with in_zip 0.6.2.0 and Winamp 5.24 with other formats (e.g. .usf), right?

Or test with 5.25 Beta? Sorry, that I have to ask.

[DrO]

if you can try it out on both versions just to make sure since there is some slight differences with the handling between the unicode (5.25) and ansi (5.24) interfaces

-daz

[Koopa]

[Edit]Your reply came to late, now I already tested with both versions.

Ok I can verify that that in_zip 0.6.2.0 works correctly with other formats.

Tested with .usf files in zip archive

in_zip 0.6.2.0 + Winamp 5.24 = verified, works fine, tags are shown

in_zip 0.6.2.0 + Winamp 5.25 Beta = verified, works fine, tags are shown.


Just 5.25 Beta and .spc files don't work, it shows the path to the temp folder instead of the tag.

[DrO]

i'm wondering more if maybe there's an issue in snesamp since in_zip just passes things through and if it's having the path returned then the title value isn't even being returned back i think. not something i can check until tonight and in the mean time i'll have a think through what else could be causing that since it's not right if other plugins are still working correctly.

-daz

[Koopa]

i'm wondering more if maybe there's an issue in snesamp

Maybe I could test it with Peter's old in_spc.

Just made another test, .psf files in rar archive works fine too with 5.24 and 5.25 Beta (using in_zip 0.6.2.0)

When you're right, that the issue is related to SNESAMP, then I'm sorry for bugspam, it's just curious, that SNESAmp shows the tag correctly, when the file is not part of an archive.

[DrO]

the result of it so far was being able to fix one nasty bug on pre 5.25 installs and some better code handling for the unicode side of things so it's not been wasted at the moment

at the moment the only thing i can think of is to look at the snesamp code to see what it's doing when i call it's gettitleinfo(..) function and try and work out what it's doing in there or not. or it could be there is something wrong with in_zip but we shall see...

-daz

[DrO]

Originally posted by Mouser X
I've had Winamp up and running since before you (officially) released 0.6.1.4, so I haven't installed 0.6.2.0 until just a few minutes ago. However, I've had a really nasty thing happen a few times, where my PC pretty much locks up nearly completely. Everytime this has happened, it happened during an extraction process, so between songs playing. The problem is, that everytime this problem has happened, I'd been playing from ZIPs or RARs, or something (probably ZIPs, in this specific case) for probably close to 24 hours. Since I just barely installed in_zip 0.6.2.0, it'll take me a bit of time to confirm whether or not this possible bug is still present. And, since I'm leaving for a trip very early Thursday morning, I may not be able to do that, since I might not have Winamp open and playing long enough...

i'll try and setup a longevity test on my end since it's entirely possible there could be some issue with repeated extractions over a long time (due to testing, etc i'm lucky if winamp remains open for over an hour). thanks for the heads up and i'll see what i can reproduce if there is anything or it's just your install being funky again

-daz

[DrO]

i've had a look through what i can of the source code for snesamp and it's title handling function and i can't see anything weird that would cause things to fail to the point where it would only display the filepath of the temp folder (if i hard code in_zip it to not call those functions then i still only get the base zip:// entry displayed as the title). so something funny is going on with the 5.25 install you have koopa. is there anyway you mind trying a clean 5.25 test install to see if that has any effect or not?

-daz

[Koopa]

Tried clean install on 2 maschines, and it still shows the path to the temp folder instead of the tag.

Now I will check, if your fix in 0.6.2.0 really fixed it for Winamp < 5.25 or if older in_zip versions working fine with older Winamp versions too.

Then I test, if I can reproduce it with Peter's ol' in_spc.

[Edit]Just working fine with Peter's old in_spc.dll, so this bug seems to be related to SNESAmp.

But Peter's plug-in is outdated, has bugs and less features then SNESAMP

[DrO]

well at least it narrows it down to a in_zip/SNESAMP conflict though i'm really wondering what is giving the issue. i'll try and make a test build over the next day or so to output some of the values being returned to see if it's possible to see what on earth is going on (seeing as it seems to be working ok on my end )

-daz

[Koopa]

seeing as it seems to be working ok on my end

Yeah but SNESAmp is weird, sometimes it plays .rsn files, sometimes it doesn't, for others .rsn support stopped working with version 3.2, so no big surprise for me, when it works on your system and not on mine.

We use different windows versions too. Can you remember the old bug in in gen_ff I reported? Egg never was able to reproduce it, I guess I've found the reason. English windows versions use a . for separating decimal places, in German we use ,



I'll check if older in_zip versions work with WA < 5.25

[DrO]

i'll have to have a check of that setting and anyothers (just incase). and i worked out the reason for why i was having issues with just one archive, it somehow had gotten into my test ml install, doh.

----------------------------------------------------------

potentially there will be a new version out in the next day or so. this is needed so that the title display will work correctly with 5.25 (since the api was changed to be fully unicode instead of partially as has been the case with most of the 5.25 betas) so the last few in_zip builds will not work correctly with 5.25 final.

as well with benski's helpful comments handling of the EQ such as with mp3's in archives will now work correctly since as it currently stands it will either be double-applied or it just won't work correctly as expected which isn't very good though since in_zip is mainly for game music archives (from the response i've had it's not something that would have showed up generally) but hey it's now fixed

and a final one, i'm nearer to getting the request Mclane had for in_nes/*.hes files+playlist which is involving a number of internal changes to allow for such situations to be handled but ordering of entries based on the first playlist found and to just cope with Mclane's request are almost there.

so depending on how the latter part goes, there will be one or two new builds in the next few days

-daz

[falcn]

Thanks DrO, your plugin is brilliant for use with any p2p network.
I love it

[ByTor201]

Originally posted by DrO

potentially there will be a new version out in the next day or so. this is needed so that the title display will work correctly with 5.25 (since the api was changed to be fully unicode instead of partially as has been the case with most of the 5.25 betas) so the last few in_zip builds will not work correctly with 5.25 final.

Hopefully, there's a new version soon as the latest beta does break in_zip.

[DrO]

you'll have to give me a day or so since it's taking longer to fix the issues with the new code that's gone into the plugin to handle playlist extraction and ofcourse nothing is ever guaranteed to be stable with beta supported releases (just a shame the change needed wasn't realised until a while after i'd added 5.25 support into in_zip). i will add that the dev build of in_zip that i have will work correctly with the current 5.25 beta and up now with title display but fixing some of the zip handling code issues i've got means i can't release a new build as is (since it internally has too much broken)

-daz