next »

[Fraggie]

Shoot, should've checked that too...

I suppose that's how RealNetworks is making money. By making Real Audio format completly incoherent.

[Dotpitch]

I suppose that's how RealNetworks is making money. By making Real Audio format completly incoherent.

You guys have no idea how much a mess RealAudio really is... RealMess.

It's rather closed source, so they probably don't really bother about consistency or clarity as long as it works properly. And ofcourse, this only make the position of RealPlayer stronger .

[Fraggie]

I just tried that Cooker file and it plays fine here, without any skipping. This file has the same problem as the ATRAC one, so I'd suppose the problem should be gone now. If you have any other Cooker file that is problematic, please upload it too.

[Dotpitch]

I just tried that Cooker file and it plays fine here, without any skipping.

Over here it doesn't play correctly, but it's hard to notice. At 1:20 and 2:40, the silence is extended. I guess it's just coincidence that both of the occurences in the file are at a silence? The ATRAC file seems OK.

[edit]Looking at the picture, it also seems RealPlayer plays the inverted signal on both channels. Or xmp-ra, ofcourse .[/edit]

[SmartOne]

Yes, thanks for the analysis.

[Fraggie]

I think it's correct now. Please check...
http://dhost.info/pieknyman/bin/test/xmp-ra.dll

Looking at the picture, it also seems RealPlayer plays the inverted signal on both channels. Or xmp-ra, ofcourse .

I wonder if it's inverted only with Cooker/Generic or maybe with every other codec/interleaver too...
Do you have some free time, Dotpitch?

[Dotpitch]

I think it's correct now. Please check...

Seems to work properly over here. Note that the first sample still silently crashes XMPlay at 00:09 at my system.

Looking at the picture, it also seems RealPlayer plays the inverted signal on both channels. Or xmp-ra, ofcourse .

I wonder if it's inverted only with Cooker/Generic or maybe with every other codec/interleaver too... Do you have some free time, Dotpitch?

I was wrong, playback by xmp-ra and RealPlayer have identical phase. When using the WAV Writer (like in my previous post), things get mixed up somewhere, either in XMPlays output or in Audacity's import. I'm using 32-bit float.

[SmartOne]

Thank you!

[Fraggie]

Seems to work properly over here. Note that the first sample still silently crashes XMPlay at 00:09 at my system.

Please try to play this file without any other plugins installed. If it still crashes, I can send you a debug version to get some clues.

[Dotpitch]

Please try to play this file without any other plugins installed.

You're right, from the fact that it crashes silently I could've guessed that it was xmp-scrobblers fault . It probably has problems with the '/' in the title. The tracks works fine when I disable it, thanks .

[Fraggie]

Excellent. 

So the plugin's almost on track - apart from djray's BBC interruptions...

[Brian]

Sorry to be a nuisance, but I can no longer play BBC News streams. For example, this stream will play in Media Player Classic but not in XMPlay:

http://www.bbc.co.uk/worldservice/meta/tx/nb/newshour_au_nb.ram

XMPlay just gives up trying to connect after about five seconds. Many thanks.

[Dotpitch]

XMPlay just gives up trying to connect after about five seconds. Many thanks.

xmp-ra requests the stream, but it gets a link back:

http://http-ws.bbc.co.uk.edgesuite.net/generateram.esi?file=worldservice/css/nb/newshour.ra&BBC-UID=[UID]&SSO2-UID)

It doesn't know what to do with it, so it just re-requests the stream until it is marked as dead. Other players perform a GET request on the link, which opens up the real stream. Manually following the links allow XMPlay to play the stream as well.

[Brian]

Dotpitch - thanks for this. Is it XMPlay itself that doesn't perform a GET request, or just the plugin? If it's the plugin, perhaps Fraggie could look into the issue, please.

[Dotpitch]

Is it XMPlay itself that doesn't perform a GET request, or just the plugin? If it's the plugin, perhaps Fraggie could look into the issue, please.

I don't know, but my best guess is that xmp-ra just treats the link are a malformatted packet and tries again on the old adress.

[SmartOne]

ddnt3260.dll

^^^ Isn't sensed by the plugin.  Only eight codecs are reported in About window.  Is this correct? Ten DLLs are in my folder.  The other that isn't listed is the C++ runtime.

[Dotpitch]

ddnt3260.dll isn't sensed by the plugin.  Only eight codecs are reported in About window.  Is this correct? Ten DLLs are in my folder.  The other that isn't listed is the C++ runtime.

From the very first post in this thread:

Codecs:

• ...
• dnet.dll & ddnt.dll - for RealAudio 3.0 support
• ...

PNCRT.DLL will go to the Windows/System32 ...

The C++ runtime is obviously not a codec.

[SmartOne]

I know!  Where do you think I got the information in the first place?  Again, what about ddnt.dll?  Should that be reported by the About window?

I have the C++ runtime in my "PATH." (C:\Program Files\xmplay342\plugins\real)

 

[Fraggie]

XMPlay just gives up trying to connect after about five seconds. Many thanks.

xmp-ra requests the stream, but it gets a link back:

http://http-ws.bbc.co.uk.edgesuite.net/generateram.esi?file=worldservice/css/nb/newshour.ra&BBC-UID=[UID]&SSO2-UID)

It doesn't know what to do with it, so it just re-requests the stream until it is marked as dead. Other players perform a GET request on the link, which opens up the real stream. Manually following the links allow XMPlay to play the stream as well.

The plugin should follow HTTP links automatically. I need to check what's stopping it here.

I know!  Where do you think I got the information in the first place?  Again, what about ddnt.dll?  Should that be reported by the About window?

Both DLL's are required to decode the same codec - DolbyNET, but only dnet.dll is a valid "RealAudio codec DLL":
  - dnet.dll - loads ddnt.dll; has standard RealAudio API,
  - ddnt.dll - the actual decoder engine with custom API.

Actually DolbyNET is just AC3 with reversed byte order, so maybe RealNetworks didn't get the source code, but just a DLL from Dolby? I don't know, but there surely must be a reason why they keep this codec's binaries splitted.

[Brian]

Fraggie - thanks for looking into the GET issue. I think the BBC must have changed the way its streams are handled, because I never used to have this difficulty.