Stereo Tool

Hey,

We've been testing Stereo Tool for a few days as a server-side processing tool on a Debian Linux system and found a strange issue. We tried both the native Linux command line version, and stereo_tool_cmd.exe (under wine). This is the command we used:

ogg123 -d wav -f - http://ip:port/mount.ogg | ./stereo_tool - - -s mypreset.sts | lame -h -b 320 - - | ./shoutsend -m /mount.mp3 -s 127.0.0.1 -p 8120 -P ******

The problem is that Stereo Tool suddenly exits after a few hours (usually after 203 minutes or so) without any error message or log entry. We had even replaced ogg123, lame and shoutsend with other software then tried again. Could you please help us figure out what or where the problem might be?

Hm, at 44.1 kHz, 16 bit stereo, that would be exactly 2 GB of data. Which - at least in Windows - is the maximum file size for 'normal' files (otherwise you have to use something called 'large file mode').

So I guess I need to open files or stdin in 'large file' mode to fix this. Will look into it asap.

It seems to be fixed now (at least in the Linux version). See the latest BETA in this thread: viewtopic.php?f=14&t=2661&p=6531#p6531

(I'll leave it running here for the rest of the day to see if it keeps working).

Hi,

Unfortunately, the problem still persists in the latest beta.

Odd - I've let it process 24 hours of data (it runs at a higher speed because I'm sending the output to /dev/null, but that shouldn't matter), and it's still running.

Are you sure that it's not one of the other programs? If you remove Stereo Tool from the chain, does it keep running?

There are quite a lot of programs that suffer from this behavior - that is, the 2 GB file size limit. That's because older file handling commands use 32 bit variables for the file size instead of 64 bit values - any program that doesn't pay attention to this issue will stop after 2 GB.

For example, in your command line I see that you use 'ogg123 -d wav' - elsewhere (I just Googled it) I found that .WAV files cannot be bigger than 2 GB... So that's one possible problem - on top of that, LAME might stop if it gets a .WAV file as input if it exceeds 2 GB. See for example this thread: http://www.hydrogenaudio.org/forums/lof ... 63636.html

(Actually, this is very likely - the WAV file header (first 44 bytes) contains the file size, which is of course not known in this case. So it probably fills in the maximum value - which is 2 GB...)

So could you test it _without_ Stereo Tool?


I think I should definitely start supporting some Linux audio formats (at least .au files) instead of only supporting .wav files....
Also in the (near?) future I want to support recognition of the input format, and choosing a different (higher) output sampling rate for - for example - FM RDS and stereo information. But I probably won't do that for version 5.10 yet.

I've been testing for a few days, and the results are confusing. I began with a 5 hours long file then a live stream.

Here are test results with a ~5 hours long input file:

ogg123 -d raw -f - infile.ogg | ./stereo_tool - outfile -s mypreset.sts

Correct.

ogg123 -d raw -f - infile.ogg | ./stereo_tool - - -s mypreset.sts | lame -r -b 112 -q 9 - outfile.mp3

Correct.

ogg123 -d raw -f - infile.ogg | ./stereo_tool - - -s mypreset.sts | lame -r -b 112 -q 9 - - | ./shoutsend -m /mount.mp3 -s 127.0.0.1 -p 8000 -P ******

Correct.

...but with an input stream the following command caused "Disconnecting source due to socket timeout" error in Icecast after 406 minutes (that is, 2*203 mins):

ogg123 -d raw -f - http://ip:port/mount.ogg | ./stereo_tool - - -s mypreset.sts | lame -r -b 112 -q 9 - - | ./shoutsend -m /mount.mp3 -s 127.0.0.1 -p 8000 -P ******

However, Stereo Tool seemed still working after the error, so I wonder where the problem might be.

Then I did some tests without Stereo Tool:

while true; do cat infile.ogg; done | ogg123 -d raw -f - - | lame -r -b 112 -q 9 - outfile-loop.mp3

Correct after 3 rounds.

Obviously, more tests are required. I'm investigating the problem right now and will post an update in a couple of hours.

Edit: As you can see, this time I used RAW mode everywhere instead of WAV.

Here are some result without ST:

while true; do cat infile.ogg; done | ogg123 -d raw -f - - | lame -r -b 112 -q 9 - outfile-loop.mp3

Correct.

ogg123 -r -d raw -f - http://ip:port/infile.ogg | lame -r -b 112 -q 9 - outfile-loop.mp3

Correct.


And here are the test cases with ST beta 15:

while true; do cat infile.ogg; done | ogg123 -d raw -f - - | ./stereo_tool - - -s mypreset.sts | lame -r -b 112 -q 9 - outfile-loop.mp3

FAIL! (at 406 mins)

ogg123 -r -d raw -f - http://ip:port/infile.ogg | ./stereo_tool - - -s mypreset.sts | lame -r -b 112 -q 9 - outfile-loop.mp3

FAIL! (at 406 mins)


Considering these, the problem is definitely in Stereo Tool. The previous results were misleading as my ~5 hours test file was shorter than 406 minutes. As you tested with /dev/null, you couldn't notice the thing that, after 406 minutes, ST seemingly keeps running (see the screenshot below) but doesn't write any more data into the output file. Moreover, when the counter in the lower left corner reaches ~2 GB it starts counting 'up' from -2 GB to zero (maybe an overflow).

I hope these results will be useful to resolve the issue. (The tests were made on a virtual machine running Debian Squeeze x86.)

Update:

I let ST count up to zero. Then it started counting to +2 GB again, and also started writing into the output file.

Aha! At least the negative values thing was solved in BETA510-16, but I never mentioned it because I didn't think it was important... Will have to check if this now also means that the data is being written correctly or not.

I tried beta 16 in the morning with a looped file, works fine. Now I am testing it with a live stream, will post an update at midnight (CET).