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: Otachan's in_!mpg123 (Read 215418 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Otachan's in_!mpg123

Reply #50
Quote
What is KX Project?

Q => A

EDIT: amano beat me to it.
"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
        - Oceania Association of Autonomous Astronauts

Otachan's in_!mpg123

Reply #51
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. =/
"We live as if the world were as it should be, to show it what it can be..." - Angel

Otachan's in_!mpg123

Reply #52
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.

Otachan's in_!mpg123

Reply #53
Quote
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
Sorry for my English.

Otachan's in_!mpg123

Reply #54
Or that would work 

Otachan's in_!mpg123

Reply #55
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.

 

Otachan's in_!mpg123

Reply #56
@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
Sergio
M-Audio Delta AP + Revox B150 + (JBL 4301B | Sennheiser Amperior | Sennheiser HD598)

Otachan's in_!mpg123

Reply #57
@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.

Otachan's in_!mpg123

Reply #58
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...
<name>madoka</name>

Otachan's in_!mpg123

Reply #59
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.

Otachan's in_!mpg123

Reply #60
Quote
.... 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
Sergio
M-Audio Delta AP + Revox B150 + (JBL 4301B | Sennheiser Amperior | Sennheiser HD598)

Otachan's in_!mpg123

Reply #61
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...
"We live as if the world were as it should be, to show it what it can be..." - Angel

Otachan's in_!mpg123

Reply #62
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?

Otachan's in_!mpg123

Reply #63
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+).

Otachan's in_!mpg123

Reply #64
Erm, kinda need/like the gapless :*(


i hope it gets fixed

Otachan's in_!mpg123

Reply #65
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. =)
"We live as if the world were as it should be, to show it what it can be..." - Angel

Otachan's in_!mpg123

Reply #66
@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

Otachan's in_!mpg123

Reply #67
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]

Otachan's in_!mpg123

Reply #68
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 

Otachan's in_!mpg123

Reply #69
Quote
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.

Otachan's in_!mpg123

Reply #70
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.

Otachan's in_!mpg123

Reply #71
Quote
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.
Sorry for my English.

Otachan's in_!mpg123

Reply #72
@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

Otachan's in_!mpg123

Reply #73
@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).