Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Updated in_mad Winamp MAD MP3 input plugin (Read 303488 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Updated in_mad Winamp MAD MP3 input plugin

Reply #225
For the last month or 2 builds, I get memory errors/crashes with using this plugin in Mediamonkey (compatible with WA2 plugins).

Unfortunately it got so bad I had to stop using it, but if I can help narrow down the problem somehow I will.

Updated in_mad Winamp MAD MP3 input plugin

Reply #226
The EQ gapless problem is due to CPU usage (again) causing it to skip on my laptop. I'm going to look into reducing the amount of repetitive things that happen in the decoding loop etc.

@Teknojnky, I've not checked in_mad in Mediamonkey for some time now, I'll reinstall it and look into it.

The main list of bugs now are volume reducing on seeking, MediaMonkey problems, Icecast VBR title problems and more CPU usage/speed problems. I'd also like to get Winamp 5.3 global settings working.

Thanks to all for comments and testing

Updated in_mad Winamp MAD MP3 input plugin

Reply #227
I've uploaded an update to the usual place.

I've made some changes to seeking, RG behaviour, and both input and output buffering in an attempt to reduce CPU usage. I've also made changes to the shoutcast header parser hopefully allowing more streams to be played.

@Teknojnky, what other plug-ins are active in MediaMonkey? what tags are on the files your trying to play? I've clean installed it and tried it with various DSPs and options but can't make it crash.

Updated in_mad Winamp MAD MP3 input plugin

Reply #228
I don't actively use many special plugins, however the main ones are gen_audioscrobbler.dll (new style last.fm plugin), minilyrics (v 2266), and the DS_out.dll from winamp 5.21 (says v 2.42).

When not using the mad plugin, I use either in_mp3 from winamp 5.21, or sometimes the default MM plugin.

As far as tags, MM uses id3 2.3 format. My own rips I use cbr 192, but I have lots of varying types of encodings from whenever and wherever.

I'll load up the lastest mad and see if I can find a file which has problems.

As to why I use 5.21, I beleive it was the last release of winamp which plugins work in MM. Newer releases plugins have changed something so that MM can't use them.

Updated in_mad Winamp MAD MP3 input plugin

Reply #229
Hi
I have found a small bug in the id3v2-tags. My with Lame tagged files have in Genre a number instead of the actual Genre.  Otherwise it's a great plug-in and i love your work
Btw: The bug with volume reducing in seeking hasn't been solved for me.

Updated in_mad Winamp MAD MP3 input plugin

Reply #230
I'll have to take a closer look at the volume reducing bug, and I'll fix the genre problem as well. 

@Teknojnky, I'll test MM with the plug-ins you mention and in_mad, hopefully it'll shed some light on your problem.

Updated in_mad Winamp MAD MP3 input plugin

Reply #231
Seeking seems to be doing much better now.  I don't think I'm getting any more audible glitches. (will continue to test though)

edit: Seems to freeze up winamp a lot.  Always at the end (and possibly beginning) of some mp3's (my nice old partially corrupt ones).  Sometimes results in 100% CPU usage, other times I can just hit the stop button and advance to the next track.  I've reverted to the previous version to see if the problems still occur.
Vorbis-q0-lowpass99
lame3.93.1-q5-V9-k-nspsytune

Updated in_mad Winamp MAD MP3 input plugin

Reply #232
I have to ask...is this preferred to Otachan's mpg123 for any reason? Is it more accurate or better features? Otachan's is updated once or twice a month and I see no discussion about it in its thread. 

Updated in_mad Winamp MAD MP3 input plugin

Reply #233
I have to ask...is this preferred to Otachan's mpg123 for any reason? Is it more accurate or better features? Otachan's is updated once or twice a month and I see no discussion about it in its thread. 


I switched from Otachan to MAD mainly because the latter offers full tag editing support for both ID3 and APEv2. The last Otachan version I tested opened the native Windows properties panel when I checked the info of an MP3 file, which was really useless in the case of my APEv2 tagged MP3 collection. It also offers a nice Gap Removal function for non-LAME encoded files and ID3v2 equalizer as well as streaming support. In the case of MAD we also have a very dedicated developer who reads both bug reports and suggestions in this topic. Cheers @ MoSPDude!

Updated in_mad Winamp MAD MP3 input plugin

Reply #234
I from Russia. MAD does not support the russian text in tags...
Possible this correct and as?

Updated in_mad Winamp MAD MP3 input plugin

Reply #235
I from Russia. MAD does not support the russian text in tags...
Possible this correct and as?


ENG: Author knows it and works on it

RUS: ????? ? ????? ? ???????? ??? ????

Updated in_mad Winamp MAD MP3 input plugin

Reply #236
Hello MoSPDude

Is there any fixes to original in_mad 1.14.2-beta code in your modification?

Updated in_mad Winamp MAD MP3 input plugin

Reply #237
@nogus, this plug-in started out as an upgrade of the code to the 0.14.2b plug-in with basic ID3v2 support using libmad 0.15.1b and libid3tag 0.15.1b. From there I've added large parts to it such as the enhanced ID3v2 support, APE tag support and shoutcast support, and re-written a few old troublesome sections such as the decoding loop. The most heavily changed library in this plug-in is libid3tag as I've fixed it so it writes correct ID3v2.3 and v2.4 tags.

@gameplaya15143, I'm holding off on an update while I solve the end of track problem. It occurs very rarely (like that volume bug!), but I've had it happen now twice.

I've also managed to fix the volume bug ready for the next release, hopefully for good! 

Thanks to everyone for all support, testing and comments 

Updated in_mad Winamp MAD MP3 input plugin

Reply #238
my in_mad mod

I just found MoSPDude's modification. I thought there is no modifications. So i compiled in_mad 0.14.2.beta with msvc60 against 0.15.1 mad libraries and just used ID3V2 tag editor from in_mp3.dll (there is call to in_mp3 InfoBox function).
Changes to in_mad 1.14.2 code is minor, just one minor fix, so therefore i asked about known bugs in 0.14.2.
It supports cyrillics in tag values.
The untested issue is how id3v2 creation wil interfer with same file playback.
If somebody interested:
http://rapidshare.de/files/36213437/mad-0.14.2b.p1.rar.html

About SSRC

I have found out_wave_ssrc 2.0.2a source code by Peter Pawlowsky. He used old version of ssrc resampler by Naoki Shibata. I wanted to compile out_wave_ssrc against new SSRC 1.30 but unfortunately resampler is not convenient for external usage so people just cut-n-paste some code from it. Peter made nice OO refactoring of SSRC library. But it is OLD SSRC code and no easy way to update it

There is allso Besweet DLL based on version 1.28 of Naoki SSRC code. People expecting 1.30 dll from BeSweet. Sounds good but: BeSweet can't redistribute SSRC code due to LGPL license...

Conclusions:

1. Naoki resampler needs library interface! There is some reasons to use Besweet SSRC DLL. Or find some automated way to make library from Naoki SSRC resampler. Certainly best way is to ask Naoki to part his code into normal lib and frontend.
2. Resampling, dithering and shaping is output module business. Best solution is SSRC output module that chains to any Nullsoft output module.

Cheers,
Oleg

Updated in_mad Winamp MAD MP3 input plugin

Reply #239
Dithering and shaping are not necessarily just for the output module, it should be used whenever there is a bit-depth conversion. libmad uses a 28-bit fixed internal representation. The dither and noise-shaping are applied when the 28-bit output is reduced to 8, 16 or 24 bits (the 32 bit output is simply 24 bits padded).

The old 0.14.2b plug-in applied simple triangular dither and a basic 2nd order noise shaper. In my updated in_mad the only parts used from SSRC 1.30 are the co-efficients for the noise shaper at different sampling rates, and the methods for generating and applying the dither.

In terms of bugs in the 0.14.2b code, one I remember is in the Xing tag reader - I merged the Xing/LAME tag reader from the latest madplay as that was more updated and fixed that. Another is the internet stream hijacking problem due to "is_ourfile" behaviour. Feel free to look at my updated source code and apply fixes, although if you are going to apply huge sections of code such as decoding loop, please would you add some recognition to the About box. Thanks

Updated in_mad Winamp MAD MP3 input plugin

Reply #240
I've uploaded an update to the usual place.

This hopefully will have solved both the volume reducing on seek and sync error, and the end of track problem. I've also fixed the genre problem, converting genre names back to numbers (and back again) as in the specification. Improvements have also been made to the gap removal feature on tracks without gapless information - the threshold for silence can also be set.

I've been trying to access WA5.3 global settings, but my C to C++ wrapper crashes.  Does anyone know of a way to access them without going through class pointers?

@Teknojnky, I still can't make MediaMonkey crash. The only plug-in you mention that I haven't been able to test is the gen_audioscrobbler.dll, if you could check that by disabling it for me. Otherwise I've tested the latest minilyrics and the DS output plug-in you mentioned, with the latest MediaMonkey. What OS are you using? Does in_mad crash winamp on your machine?

Thanks for all help, bug-finding and comments in advance. 

Updated in_mad Winamp MAD MP3 input plugin

Reply #241
I've uploaded another quick update to the usual place.

This now has (hopefully) sample accurate seeking - its disabled by default. I haven't properly tested it so all comments are welcome. 

EDIT: There is a bug in the accurate seeking that puts it way off. I've sorted most of it out but am still out by a few samples. I'll hopefully get it fixed for an update later.

EDIT 2: It turns out that on my test files instructing winamp to seek to 2 minutes actually seeked to 120092 ms, which was the exact output I was getting. I've uploaded this new version, all other files and seeks seem to be working

Updated in_mad Winamp MAD MP3 input plugin

Reply #242
I'll have to redownload to make sure I have the latest version.

Accurate seeking worked fine for me, no audible glitches, and it has yet to crash.

Excellent work!

edit: There is still a problem that hasn't been resolved.  At the end of some of my lovely slightly corrupt mp3's, in_mad ends up in an infinite loop (CPU 100%).  I can still use 'stop' and 'next' without crashing winamp.  This happens both with and without the gapless option on, the accurate seeking option doesn't effect it either.
Vorbis-q0-lowpass99
lame3.93.1-q5-V9-k-nspsytune

Updated in_mad Winamp MAD MP3 input plugin

Reply #243
@gameplaya15143, can you tell me what it says in the Buffer information tab in the File info window when it enters its infinite loop. (The option to show the buffer information is at the bottom of the Buffer configuration page). I'm mainly interested in the length of the input buffer, and status of end of input and end of decoding flags.

Come to think of it, I might know what is causing the trouble if the file is damaged at the end - I'll have another go at it later today for an update tomorrow.

Thanks 

Updated in_mad Winamp MAD MP3 input plugin

Reply #244
The 'end of input' box gets checked, and the input buffer goes down (as it should).  On the files where it is looping, the 'end of decoding' box does not get checked.  There is still a lot in the decoding buffer when it runs into this problem.

I hope that helps
Vorbis-q0-lowpass99
lame3.93.1-q5-V9-k-nspsytune

Updated in_mad Winamp MAD MP3 input plugin

Reply #245
It appears that it's stuck in a while loop at playback.c line 639. Specifically, after call to mad_frame_decode fails, it breaks there:
Code: [Select]
  if (input_buffer_cycle(input_buffer, stream.next_frame, &input_ptr, input_length, input_size) == -1)
                        {
                            //we've EOF and its not because we're at the end of memory
                            err_buflen = 1;
                            break;
                        }

and goes here:
Code: [Select]
  if ((err_buflen == 1) || (eof_decode == 1)) continue;
            if (err > 0) break;

Since err_buflen is set to 1, it continues to the start of the while loop again and again. While loop condition checks if eof_decode==1, so i set it before continue:
Code: [Select]
if ((err_buflen == 1) || (eof_decode == 1))
                {
                eof_decode=1;
                continue;
                }
            if (err > 0) break;

and it seems to work. Well it's not that i understand the whole process, this is only a dirty hack.

Updated in_mad Winamp MAD MP3 input plugin

Reply #246
Yep, kairo is right. The behaviour when its ran out off data but not at the end of the buffer memory should halt the decoding because there is no more valid data and we're end of file. The err_buflen should have continued to the outside loop (my mistake) so as to fetch more data from an internet stream.

I've uploaded an update to the usual location. Thanks for everyone support and helping me track down these problems.

Updated in_mad Winamp MAD MP3 input plugin

Reply #247
Here is a small present for you MoSPDude, this one crashes in_mad even when it just tried to read the tag. (result of a 'bad cut')  I think this is the only file I have that is still causing problems.

As far as streaming goes.. I tried listening to a shoutcast mp3 stream, in_mad did not pick it up.  It also gave me an error when trying to listen to an icecast mp3 stream (../listen.mp3) saying 'file could not be located on disk' or something.  I tried opening the file info dialog, when I clicked on the 'buffer' tab (which shouldn't have been there since it wasn't playing) in_mad crashed.  I have no problems like these streaming from shoutcast or icecast on my own machine (localhost).  It seems to just not like outside sources.

The first 'problem' may be due to the fact that I am using some random letters for winamp's default type for unknown files (same random letters on the extention list of in_mp3).

As always, thanks for the great plugin!
Vorbis-q0-lowpass99
lame3.93.1-q5-V9-k-nspsytune

Updated in_mad Winamp MAD MP3 input plugin

Reply #248
Apparently, something is wrong with buffering algorithm in scan_header() (same playback.c), but I can't figure out where exactly. It keeps calling memmove() with source=destination.

As another quick-and-dirty hack, simply enlarging buffer from 1536 to 15360 bytes seem to do the trick. Well, at least this broken track plays now 

Updated in_mad Winamp MAD MP3 input plugin

Reply #249
I'm playing with a way to fix this, I'm not quite happy with it yet.

I believe its to do with libmad and how it sets stream.this_frame and stream.next_frame when there is an error. I think its supposed to (correctly) set stream.next_frame = stream.this_frame + 1 , so in an error it steps byte by byte to find a correct header. On other occassions though it leaves it stream.next_frame = stream.this_frame (which ends up equal to the start of the buffer) entering the loop problem.

I try to avoid modifying libmad and libid3tag unless I really need to, but I think I'll have to have a proper look into libmad for this one.