The read_file.dll is a really powerfull .dll which was/is shipped in:
+ Winamp 2.7 and ++ + Winamp5 + Peter Pawlowski's Plug-ins Package (4P) ( In this package there is also an non-public TFMX input plug-in, which is much, much more better than this one: http://listen.to/tfmx . There is further great stuff inside the package, which was never be published on Winamp's plug-ins page. Take google and web.archive.org to try get the Plug-ins Package.
Or ask me to get this great package. )
The read_file.dll can be found in Winamp's plug-in directory.
Well, nearly nobody really knows all the features that the read_file.dll has:
1.) ARJ/RAR/ZIP archives will be handled as directories. ========================================================
With the help of read_file.dll, Winamp can directly open files in archives.
Example for what is Winamp (& the certain input plug-in + read_file.dll) currently able to handle:
To avoid to search manually, Peter Pawlowski also built a great Windows Ripper tool which can detect embedded stuff (music, midi, video, graphic related) in different files:
"WinRipper".
While scanning files with "WinRipper" you can: + extract ripped files to a certain place or + add the ripped tune as a playlist entry in/to winamp automatically.
For example, scan your Command and Conquer, ..., Red Alert CDs with WinRipper and you should get playlist entries like these:
Command and Conquer Tiberian Dawn game music: (inside scores.mix ; "#" describes any CD drive)
Before scanning, disable the "convert to .wav" switch in WinRipper's both AUD settings and enable: "send files to Winamp without extracting" (Winamp should already be opened, before/while scanning files.)
etc...
Many other games / game container files and file formats (e.g. midi, mod,...) are also supported.
After rippping, check the Waveform Decoder Plug-in and enable AUD support.
Now you can play files from your Command and Conquer CDs/CD Images directly without extracting the game music.
If a file / music format from/inside a zip/rar archive can be played or not, only depends on the input-plugin which has: "read_file.dll" support.
Here you can get an example of: + a .rar file with tfmx tunes + a .m3u file to play the tfmx tunes inside the rar archive + the best (but not really known) TFMX plug-in for Winamp.
http://bnobtc.pix-art.com/winamp/
Here is a list of input plug-ins which use the "read_file.dll" + to handle areas as files and + to handle zip/rar archives as directories:
Input plug-ins with read_file.dll support:
+ Nullsoft MIDI Player 3.07 (older versions too) [in_midi.dll]
( Notes/interesting information: The current MIDI Plug-in in Winamp5 (and in older Winamp2 releases) was 99,99999% (or 100% ?) built by Peter Pawlowski. Briefly: Nullsoft kicked Peter Pawlowski and the the MIDI Plug-in is still part of Winamp. ...you should check Winamp 1.xx or early 2.xx releases to see the differences between the old MIDI Plug-in and the new which was improved by P.P. The main part of improving all other Winamp's plug-ins was also done by Peter Pawlowski. )
*=This was the only .dll file where I could not find a read_file.dll string. That means ogg vorbis decoder plug-in maybe does not support the read_file.dll.
The latest known "read_file.dll" was built on: 20th July 2002 and the latest Winamp5 release still uses this read_file.dll version.
However, I only have a readme.txt-file from read_file.dll version: 01/25/2002 And there you can see that the ogg vorbis input plug-in should be able to play files in compressed archives/ container files.
================================================================================ read_file.dll, build 01/25/2002 (c) 2001-2002 Peter Pawlowski, http://www.blorp.com/~peter/
This dll is a part of winamp setup; it is used by my input plugins to read compressed files. in winamp3, all input plugins will use access local files via read_file.dll so you will be able to play zipped mp3s for an example. Of course, it also reads regular non-compressed files. You are not allowed to redistribute this DLL anywhere without my permission.
currently supported formats are: - zip and gzip (powered by all-time great ZLIB) - rar (powered by UnRAR source code) - arj (powered by UnARJ source code)
plugins that support read_file.dll: - in_midi (in winamp setup) - in_wave (my one, not Nullsoft's plugin from Winamp setup) - in_vorbis (will be in the next winamp setup) - in_mod (updated version will be in the next Winamp setup) - in_vqf - in_spc - in_tfmx
most of plugins listed above can be found on my web site
read_file.dll's major purpose is to decompress compressed mods / midis (archives containing single file) 'on the fly'. the file is being completely decompressed into memory while opening. be careful with this stuff - if you compress 50-meg wav, you will need 50 megs of free RAM in order to play it and it will take several seconds to open it.
new versions have some other features: - CD letter detection - replace drive letter with # character, eg. "#:\main.mix" and read_file.dll will automatically scan all drive letters for that file.
- partial file access - eg. "partial://xxxxxxx-yyyyyyyy:x:\dir\file.ext\file.mid" where : xxxxxxxx - start offset in hex (must be 8 characters!), yyyyyyyy - end offset in hex, x:\dir\file.ext - path of file, file.mid - 'display name' of file (most input plugins will recognize it as file name); extension is important to make sure that proper input plugin opens the file. example: install my in_wave, insert Red Alert CD1 english and open "partial://188391D4-18C4BEC0:#:\main.mix\Hell March.aud".
- zip/rar file extraction - eg. "c:\music\spc\FF5.rar\ff5-1-01.spc". you can compress all your SPCs with RAR and create playlists referencing RAR files; this will save huge amounts of disk space (about 30 megs for me).
TIP: if you want to compress whole directory of files, append '.rar' (or '.zip') to its name, then create big playlist with files in it, save it in parent directory, remove '.rar' ('.zip') extension, compress contents with rar/zip (make sure that rar/zip file name is the same as altered directory name before) and put rar/zip file in parent directory (where your playlist is).
*** Using read_file.dll in your plugins *** Read_file.dll is based on pre-released Winamp3 specs (Tempura). It should even still work with Tempura. (Almost) complete specs were inside Winamp3 pre-sdk which used to be available on NSDN - http://www.winamp.com/nsdn/ (and might be still there). Exported symbol is int readerSource(HINSTANCE ,reader_source**) (this is not mentioned in Tempura specs). ================================================================================
The Plug-ins listed above use the symbol/function: + readerSource
The input plug-in: "in_midi.dll" is able to convert (exotic) MIDI file formats to other / compressed MIDI files. So, it additionally uses the functions:
+ RF_create + gzip_writefile
All three functions can be found inside the "read_file.dll" and are offered by this .dll.
1.) Now, it would be really great, if you could add "read_file.dll"-support to your 64th Note USF input Plug-in. Then it would be possible to play the N64 USF tunes in "rar/zip state" without unpacking them.
Because I could not find any "read_file.dll"-related documents I did a long search and finally found good old Winamp3 SDK stuff:
I think there's a few things you should note. For one, this looks almost like a direct copy from your post at winamp.com. The other is that HCS reads Winamp, occasionaly, so I'm pretty sure this message was read by him at Winamp.
"Borg Number One" wrote: Now, it would be really great, if you could add "read_file.dll"-support to your 64th Note USF input Plug-in. Then it would be possible to play the N64 USF tunes in "rar/zip state" without unpacking them.
Last I checked, this could already be done using in_zip (which, again, is where you already posted this). Of course I don't speak for everyone, but I've never had any major problems playing USF files using in_zip to read from the RARs (other than the ones DrO knew about, and now the ones that were causing me problems have been fixed).
What I'm trying to ask is, where is the use in adding archive support into 64th Note, when in_zip already works just fine (for me at least)? Is there any specific reason? Is there something I missed? Though I'm not the programer here, I do thank you for your concern. I hope to hear your reply soon. Mouser X over and out.
Currently I'm using DrO's in_zip plugin to read from compressed files, it's working quite well. But I can see you've already found that thread and posted your message there as well... As I've stated before elsewhere I'd like to keep 64th Note only doing what it needs to do as a USF player and leave other functions to other programs. Thus there is no resampling or decompression support built in, nor do I intend to attempt to add support for read_file.dll (though I admit I'd never heard of it until now).
This is the main reasoning behind in_zip in that plugin authors don't have to then rely on another dll dependancy for extraction but instead let a pass through layer to make archives appear just like a normal file to them (which solves issues of older in_* plugins which aren't developed anymore but the formats can benefit from being stored in a archive).
you could then work off the basis that in_zip should then use read_file but since the dll doesn't support things like ace and bzip2 you then end up coming back to the same situation again of having to create the handling and interfaces for those so really it's just easier to build a new dll and have new formats bolted in as required (which in general can be done on a faster basis than any official updates to the winamp distribution).
regarding hcs's view on things, i can understand that entirely of letting something else handle specific tasks rather than bulking up a plugin that otherwise doesn't need to have that done to it. it's all a matter of choice and opinion.
1.) Mouser X wrote: this looks almost like a direct copy from your post at winamp.com
So what? Where is the problem?
In many forums you can see (too) short and really bad written posts with suggestions/problems which several user have.
So, the other one (author of the software) has to ask the user that he should describe the suggestion/problem more detailed. This really sucks.
My motto is to describe a problem/suggestion as detailed as possible.... as you can/could already see. :)
So, it took nearly a half hour to write a decent text with + introduction + main part and + suggestion.
So, why should not I copy and modify my own written text from Winamp forums to this forum?
Or why should I create a completely new text which describes the same?
Because, I did not see hcs in the winamp forums before, I just wanted to inform hcs about the interesting information about the read_file.dll.
If you should become the idea to reply this message with: "blah blah... SPAM is forbidden... blah bla" then I am sure you cannot read.
If you can read, then check the phrase two sentence backwards:
Borg Number One wrote: Because, I did not see hcs in the winamp forums before,[...]
Oh my god. :O Copying and modifying my own text was/is not a crime!!!
I just described + the situation (about the read_file.dll) and + a decent, detailed suggestion for the great 64th Note N64 Winamp input plug-in ...not more. ;)
2.) Because I generally like classic stuff (DOS, Vesa, Adlib/OPL, Midi, Amiga, C64, Amiga/C64/NES/N64-emulation, DOSBOX, etc...)
So, I like the idea to use the developed read_file.dll-"system" which was introduced by Peter Pawloski, years ago.
I also like new and interesting stuff.
So, as you can/could see in the Winamp forums, I am interested in DrO's Plugins.
Especially in "JTFE", because other I was interested in an ability to translate JTFE into other languages more easily.
Now, JTFE can be translated with a simple .ini file.
The next interesting plug-in is DrO's in_zip.dll.
Because it has new/other features than the read_file.dll-system Furthermore you do not need to implement any stuff into your plug-in to support packed archives. You just need DrO's
I will help to improove this plug-in again and I am really willing to see that DrO brings forward the development of the in_zip.dll.
Briefly:
I like good old classic stuff as good as new interesting stuff. And I am sure that the in_zip.dll plug-in will be a part of the next Winamp5.x distribution. :)
"Borg Number One" wrote: So what? Where is the problem?
No problem, really. I was simply pointing it out. Basically, I thought you could have shortened your message. As for this: Oh my god. :O Copying and modifying my own text was/is not a crime!!!
I never said it was, I didn't mean to imply such, nor was I trying to be rude. If you thought I was, please reconsider. I'm sorry you felt that way, and hopefully in the future you'll be able to see that generally, I try pretty hard to be a nice guy. Perhaps I posted that message to late last night and I was a little tired (it happens rather often, unfortunatly).
Anyway, I simply posted a few questions to try and clarify your point. Hopefully, that has been resolved. Mouser X over and out.
I'm sorry you felt that way, and hopefully in the future you'll be able to see that generally, I try pretty hard to be a nice guy.
It's true, he writes paragraph upon paragraph making his point while, at the same time, assuring his audience that opposing arguments are equally valid.