Otachan's in_!mpg123, Alternative Winamp mp3 playback plugin Options

[Mr_Rabid_Teddybe...]

What is KX Project?

Q => A

EDIT: amano beat me to it.

This post has been edited by Mr_Rabid_Teddybear: Apr 12 2004, 03:07

[NoahFrenzy]

Does anyone have a copy of in_mpg123 OT66 in either standard or SSE flavors? I updated and didn't think to save the old one; the newest versions are making Enqueuing functions in Winamp5 crash for me. =/

[Teqnilogik]

I have the OT63 version in SSE, SSE2, and Regular forms. It's a little outdated as I missed the most recent releases before OT67. PM me your e-mail address and I'll e-mail it to you in a self-extracting RAR archive if you'd like. It's just 389KB.

[rt87]

Does anyone have a copy of in_mpg123 OT66 in either standard or SSE flavors? I updated and didn't think to save the old one; the newest versions are making Enqueuing functions in Winamp5 crash for me. =/

http://i.cool.ne.jp/clspaste03/in_mpg123_118ot66sse.zip

[Teqnilogik]

Or that would work

[Wizard]

It's the first time I use this plugin (with Winamp 5.03a classic) and I have 2 mp3s which have the appropriate headers according to foobar2000, but I hear a small click at the beginning of the second track. Foobar however plays them gapless. BTW, I have set buffer-ahead on track changes at 400ms. So, latest version is not completely gapless for me.

[smz]

@Wizard:

Are you positively sure that your mp3 input is handled by in_mpg123.dll and not in_mp3.dll? You MUST remove the MP3 file extension from the configuration of in_mp3.dll

A quick way to check which input plugin is handling mp3 files is to look at the "File info" of a playing mp3. If it looks the same way as before there is something wrong with your configuration.

Cheers

Sergio

[Wizard]

@smz: yes, in_mpg123 handles the playback, I totally removed in_mp3, still no luck. I just decoded the mp3s with foobar and Winamp plays the wavs gapless. There must be something wrong with in_mpg123.

[madoka@ex-sounds]

hi

in_mpg123.dll does not have gapless decoding. if you wanna gapless decoding, please use in_mpg123.dll in combination with out_asio(dll).dll (dll version) or out_asio(exe).dll (exe version). 'cause only mp3 frame can not accurate measurement. and your soundcard has need to compliant asio.

foobar2000's one has actualized by virtual of a good design concept itself.

you may find useful? sorry my poor english...

This post has been edited by madoka@ex-sounds: Apr 14 2004, 18:51

[amano]

Try setting the buffer ahead value on track change to an even higher value, 500 or 600 ms. It is perfectly gapless for me with some test samples from peter pawlowski.

[smz]

.... There must be something wrong with in_mpg123.

@Wizard:
Weird... it SEEMS to work right here, with out_ds.dll handling the output and 800ms of buffer-ahead on track changes... I'll make more thorough testing later (sorry don't have time right now).

Oh, yes, of course the MP3 files must be created by lame (>= 3.90 ??) cause the trick is lame inserting apropriate info about padding at the end in ITS tag...

BTW, I'm using "Otachan's in_mpg123 1.18 ot67", is it the same as yours, Wizard?

@madoka: sorry, but you're wrong. in_mpg123.dll IS gapless at the above conditions. Not sure if it is with out_asio, but it definitely is with out_ds and buffer-ahead.



Sergio

[NoahFrenzy]

Thanks for the link, rt! Thank you as well for the offer, Teq. It's strange though, Winamp is still crashing upon enqueuing even with the older version. I'm mostly sure that it's related to mpg123 (when I enable the regular in_mp3 things work fine), but I could have sworn OT66 worked before...

[cyde]

NoahFrenzy, I am having the same problems.

Some of my files will NOT enque without crashing winamp completely, and its an error related to in_mp123,. according to the crash box.


It worked fine prior to updating to the newest in_mp123

Any suggestions guys?

When will there be a fixed release avalable?

[amano]

Set "in_mpg123=1" in the "JTFE" (Jump to file extension) section in the "Winamp.ini".

This will delay the songs a bit which prevents Winamp (rather the JTFE plugin) from crashing.

But note: This will break gapless playing, so songs that are enqueued in a row will not being played gaplessly (a small glitch can be heard).

Songs simply played in a row (not being enqueued) remain smooth without a gap!


The bug is known and DrO will find a better way to prevent the crash (if it is possible).

EDIT: This workaround with the setting in the winamp.ini only works with the latest versions of jtfe (0.94te+).

This post has been edited by amano: Apr 15 2004, 02:53

[cyde]

Erm, kinda need/like the gapless :*(


i hope it gets fixed

[NoahFrenzy]

Excellent! Winamp is stable again. I'm still wondering why it worked for a time and then didn't, though. I'm also missing gapless enqueuing now, but a non-crashy Winamp is more desirable I suppose. =)

[amano]

@cyde: Normal songs stay gapless. Only enqueued ones are broken.

It is better to be not gapless in a certain situation than to crash, isn't it.

DrO will have to check the inner workings of the winamp input plugins first to find the cause of the problem. This will take some time.

The problem is that in_mpg123 is gapless, because it tries not to get closed. But JTFE interrupts to play another song.

EDIT: I can't believe my eyes. DrO around here

This post has been edited by amano: Apr 15 2004, 03:14

[DrO]

ok, lets try to explain this.

the way jtfe currently works is to set the next file to play when it detects the end of the file being played. the problem with this is that the next file often has started to play and so some of the file which has been started playing can be heard.

with the case of in_mpg123 it seems to lock itself once it's playing which means i can't force it to play the next track immediately, hence i have to delay the change slightly until in_mpg123 is ready to do it which isn't ideal.

to get around the whole issue, i need to take control of the file to be played next before the file is even loaded. how i'll do that is still to be finalised though i have a few ways before i've got to try and get the winamp core altered (not the prefered choice since it's not fair on those still using the 2.x versions)

i admit the current *fix* is just crap really, just will take me a bit to implement the proper fix (with work and everything else i need to do)

-daz (please make the bugs stop, please )

[edit] yes it is me, muwhaha [/edit]

This post has been edited by DrO: Apr 15 2004, 03:16

[amano]

Tnx for clarification (I was just guessing some things together from the winamp forums).

Nice to meet you in this "unusual" location and welcome to this board, Darren

This post has been edited by amano: Apr 15 2004, 03:55

[Wizard]

Oh, yes, of course the MP3 files must be created by lame (>= 3.90 ??) cause the trick is lame inserting apropriate info about padding at the end in ITS tag...

BTW, I'm using "Otachan's in_mpg123 1.18 ot67", is it the same as yours, Wizard?

Yes, encspot reports lame 3.90 and the're vbr files. I'm using v1.18 ot67b. Thanks for your replies, smz. I'll test more tomorrow cause I won't be home by then. I'll use the Winamp diskwriter to see what it outputs and test the wavs it makes.

[fileman]

I always encounter a crash of Winamp when trying to view the tag information - the dialog appears and a half second later the crash dialog pops up. The problem persists with and without mp3infp installed. Using latest version of Winamp, in_mpg123 and mp3infp.

The crash dialog says "gen_ff" did cause the crash (gen_ff = playlist editor?). Please help, I really like the gapless output Oh and I uninstalled JTFE completely to be sure it has nothing to do with this "bug".

Regards, fileman.

[rt87]

I always encounter a crash of Winamp when trying to view the tag information - the dialog appears and a half second later the crash dialog pops up. The problem persists with and without mp3infp installed. Using latest version of Winamp, in_mpg123 and mp3infp.

The crash dialog says "gen_ff" did cause the crash (gen_ff = playlist editor?). Please help, I really like the gapless output Oh and I uninstalled JTFE completely to be sure it has nothing to do with this "bug".

Regards, fileman.

gen_ff plug-in is "Nullsoft Modern Skins Support" plugin.

[DrO]

@fileman: try it out with a classic skin to see if that still causes the issue since that will ignore anything in gen_ff afaik (and gen_ff is the modern skin support)

-daz

[amano]

@fileman:
And check out that you really have the latest versions installed: in_mpg123 ot67b, mp3infp 2.44 and winamp 5.03a. I have no problem with this combination.

If everyhing else fails, using the classic skins will circumvent the use of gen_ff. but then submit a bug to the winamp bugs forums please (with a detailed hard- and software description).

This post has been edited by amano: Apr 15 2004, 16:44

[rt87]

ot67c is out.
http://www3.cypress.ne.jp/otachan/in_mpg123_118ot67c.zip