Shoutbox

i used file alyzer and this is what ive found so far...would this effect it?


in the hexdump for baa.wav its got these strings...(these are the ones that made sense)
'Sound Forge 4.0'
'Bjorn Lynne'   wtf is that
'1997-08-28'

is that of any significance? im lookign at the others now...

baa2.wav has a much longer hex dump and the quotes above are not there...(and none of the strings make sense to me...)

My analysation

Check the Attachment

Only significatant change is the bitrate and sample rate

i dunno this one's
1(mono), bit rate: 176 kbps, edit: oh yeah and sample rate is 22 kHz

and it works

i think u were right sunshine, there was something wrong with the files probably.

quote:

---

Originally posted by Joa
they seem to work after being converted to mp3's and than back to wavs

---

by converting the WAV files from raceprouk to MP3 and back to WAV, you lost significant data. It is as you're comparing two totaly different things. Do not use such method to determine the differences between files, this will be absolutely incorrect!

quote:

---

Originally posted by Joa
i know that the files i converted did not change in "sound" quality

---

Yes they did, MP3 is a 'lossy' format, quality will _allways_ be lost.

quote:

---

Originally posted by may73alliance
would it be that plus only accepts stereo sounds? or do other mono sounds work?

---

That doesn't matter. Evenmore, the original sounds from raceprouk _are_ mono.

quote:

---

Originally posted by Ezra
I know that when you encoded the wav to mp3 and back you removed the metadata, maybe that's why plus! won't accept it?

---

No... Evenmore, not all sounds from raceprouk contain metadata. And good file converters should not remove metadata but convert it also...

quote:

---

Originally posted by Ezra
EDIT: Those sounds from raceprouk also don't have metadata, it's not that then

---

No. Some have metadata. eg: baa.wav

quote:

---

Originally posted by zaidgs
i cannot be sure, but knowing that plus! uses some decoding\encoding libraries.... these are the ones responsible for things like that....

---

That could be the case. However there is something else going on (also). See below...

quote:

---

Originally posted by zaidgs
probably patchou needs to use more\better libraries.....

---

There aren't.... Lame 3.96 and libsndfile are the top and are the best you can get... Of course that doesn't mean that there can't be bugs in them or that libsndfile can read every possible format.

This again shows that what Joa did will not do anything good (sorry Joa) unless you know how soundfiles are structured, what types exist, what types can be read, etc... (eg, know the difference between SamplesPerSecond, FramesPerSecond, SamplePerFrames, Frequencies, etc...)

quote:

---

Originally posted by Ezra
He's using the LAME mp3 encoder

---

Which is most likely not the one to blame.

quote:

---

Originally posted by may73alliance
in the hexdump for baa.wav its got these strings...

---

Unless you know exactly how a RIFF format is build up, don't attempt to interpret the hex values, they will be meaningless. Google for the specs if you wanna know

quote:

---

Originally posted by may73alliance
'Sound Forge 4.0'
'Bjorn Lynne'   wtf is that
'1997-08-28'
is that of any significance? im lookign at the others now...

---

That is called meta-data, but is of no use concearning this problem....

quote:

---

Originally posted by may73alliance
baa2.wav has a much longer hex dump and the quotes above are not there...

---

yes it is longer, it is encoded with a much higher frequency and with double channels.

quote:

---

Originally posted by may73alliance
(and none of the strings make sense to me...)

---

Then don't tackle the problem I'm sorry, but you will be wasting your time and only guessing what everything means.


--------------

Also:

quote:

---

From the changelogs:

Messenger Plus! now uses dedicated sound libraries to read sound files: Libsndfile and Lame_enc. Thanks to these great pieces of work, Messenger Plus! does not have to rely on the various codecs installed on a computer anymore. The list of supported file types is now fixed and constant for everyone: AIFF, AU, IFF, MAT4, MAT5, MP1, MP2, MP3, PAF, PVF, SF, SND, SVX, VOC, W64, WAV (PCM, A/u-law, ADPCM, GSM). It is important to note that some of these formats come in various sub-formats and that not all of them are supported by Libsndfile and Lame_enc.

---

--------------

But, the problem is somewhat "stranger" then all this...

When those sounds are played using the preview button, Plus! will popup with an errormessage saying they can't be handled. However, when you go to the detailed trimming panel, they can be played! And when you alter the trimming a very small bit, you will also be able to play them using the normal preview button. So I suspect there is something wrong with the alignment of the data/frames in the sound (not all frames are read decently read out or something, or due alignment some readin past input or something occurs)...

The problem isn't the type of sound but the length of the sound or inproper sized buffer or something I suspect, as I was able to import the same type of sounds* (frequency, bitrate, channel, etc...) without any problem.

*sounds carefully created to have the exact same properties concearning format (0x0001), channels (1), samples per second, average bytes per sec, blockalignment, bits per sample, and even chunck headers as the sounds from raceprouk. Only difference being the length of the sound...

--------------

A possible related thing (best to explain with an example): when you import the sound ni.wav and play the wave via the detailed trimming panel, the panel shows a total sound duration of 227ms. When you play it it goes only to 180ms (this can be normal though). But when you trim the sound to 180ms and play it again, the sound is randomly played till 180ms and sometimes only till 90ms...

This happens with many sound trimmings...

--------------

PS: and besides that there are still problems with:
* locking temporary files (even when files aren't open and/or aren't used by Plus! anymore)
* deletion of (or rather the lack of) not used temporary files.
* the moving of the selection in the trim control acting weird/bad with short lengths (<1000ms) and shorter selections then the sound itself.

quote:

---

Originally posted by CookieRevised
The problem isn't the type of sound but the length of the sound or inproper sized buffer or something I suspect, as I was able to import the same type of sounds* (frequency, bitrate, channel, etc...) without any problem.

---

so correct me if im wrong, u think that the bug is in how plus! uses the libaries.... ie. bug is in plus! code, not 3rd party library bugs\limitations...

anyways, patchou probably would analyze the situation and fix it if it was fixable...

Cookie's analysis is (as always) very correct, however, as I'm the only one who posseses the source code of Plus!, here is the exact reason of the issues created by those sounds:
"Abandon ship" and "This is not a drill" both have a samplerate of 15151Khz, "Baa" has a samplerate of 14000Khz. These samplerates are not common/standard and the Lame_enc library refuses to compress those files for that reason. When clicking on the "Preview Sound" button of the main sound cut window, the sound is compressed before being played so that the user knows exactly how the final file will sound like. When in the advanced cut window, the sound is not compressed and is played automatically to accelerate the search of a perfect cut. If yo7ur sound card is capable of playing sounds with the samplerate mentionned above, then that's why you hear the preview in this window.

Messenger Plus! already have a built-in mechanism to fix samplerates that are slighlty higher or lower what Lame_enc accepts. However, those rates are just too "off range" and Plus! prefers not to touch them and displays the "not supported" message.

In any case, I fixd the sound preview problem where the timer did not update properly at the end of the sound (the sound are always played entirely, it was just a display glitch).

quote:

---

Originally posted by Patchou
"Abandon ship" and "This is not a drill" both have a samplerate of 15151Khz, "Baa" has a samplerate of 14000Khz.

---

I first suspected it was due to this, but then I came to ni.wav which has a samplerate of 11025Khz (8bits, mono) which is a common used and standard samplerate, so I ruled samplerates out.

(and I came to the "length of sound"-cause because those sounds could be played with the preview after they were trimmed slightly <= although I'm not sure anymore now; I can't do it again... blah!). EDIT: found it again... With the original ni.wav, if you trim it to anything between 130 and 138ms, or to 179ms, or to 180ms, the sound is accepted


Also, attached is the original ni.wav (with unneeded "fact" chunck), a fixed ni.wav (constructed as it should have been in the first place without "fact" chunk) and a testsound (exactly the same as the file structure of ni.wav). All are 11025Khz, 8bits, mono. Only the testsound is accepted in Plus!! EDIT: if you trim the test sound to anything lower then 493ms, it is again rejected by the preview.

So, there is also something other then samplerates going on (???).

---

quote:

---

Originally posted by Patchou
In any case, I fixed the sound preview problem where the timer did not update properly at the end of the sound (the sound are always played entirely, it was just a display glitch).

---

... btw, I'll mail you about the other glitch in the trim control concearning the rounding of the time/frames. (I've mentioned this before, but at that point it wasn't such a big deal. But it is when you handling sounds <1s)

yeah, I noticed that for the ni sound too... I guess the original file had something lame_enc didn't like either, I'll check out your fixed file and see what was changed exactly (if possible, I'll use that information to improve Plus! and fix the sound before giving it to Lame_enc).