Jump to content

SonicStage 3.4 u/l and d/l Testing

Rate this topic


dex Otaku

Recommended Posts

In the thread "SS 3.4 upload woes?" by kurisu, I mentioned testing uploads with SS 3.4.

Given the oddities some users have been experiencing with downloads as well, I've also decided to see if I can reproduce their errors.

Please note that all testing I'm doing is with HiMD mode discs only. netMD mode uses a separate module and is bound to have issues that are completely separate as a result.

Uploading tests

* uploading of unmodified tracks in HiLP, HiSP, and PCM modes

<blockquote>HiLP, HiSP, and PCM uploads from both my RH10 and NH700 work as expected.

In particular, as some users have noted having problems with PCM uploads, I made multiple test recordings with both units using both line and mic in, on both a HiMD-formatted MD80 and a 1GB disc. No problems experienced on any count.</blockquote>

* handling of tracks with known write errors [known problem]

<blockquote>Unexpected results here - uploading went straight through write errors with no problems at all. The resulting tracks have clicks where the errors were. Tracks are playable on the unit both beforehand and after.

Assuming it always acts this way [which implies that error-recovery has been vastly improved], this is a major change since previous versions with their seemingly random behaviour [including erasing the tracks, erasing the tracks and all subsequent ones on the disc, skipping the track and rendering it unplayable, and other nasties].</blockquote>

* handling of very short track lengths [known problem]

<blockquote>Tested with HiLP,HiSP, and PCM modes.

Track lengths of 1 second [i.e. bouncing my finger on the T.MARK key repeatedly] upload and play properly. I haven't tried combining them yet, but since they do play, I'm assuming for now that they likely will do so properly. I could be wrong, though. If it's important enough to anyone else, please try for yourself to see what results you get.

Previous versions would create blank tracks in the library after upload if they were this short on the disc, attempts to convert to WAV would leave 0-length WAV files, and attempts to combine [at least with 3.1] would sometimes result in an error/abort.

Another improvement, though obviously not as critical as the write error issue.</blockquote>

* handling of contiguous tracks recorded via line-in and automatically trackmarked by the unit [specifically, whether combine still has the repeated section issue, which is admittedly likely a hardware problem]

<blockquote>Same results as before, as expected. This is a hardware issue and would require seeking through track ends/beginnings [like HiMDRenderer does] in order to be fixed.

The easiest solution is still not to combine recordings made via line-in with SS, rather to use other editing software afterwards.</blockquote>

Downloading/encoding tests

A note before everything else: downloading compressed tracks with SS 3.4 to either my NH700 or RH10 appears to be significantly slower than it was with SS 3.3. I'd estimate that it takes at least 50% longer for a given track than it used to, and there's no difference between downloads of MP3 or a3/a3+ tracks of the same bitrate. Needless to say, this seems odd to me. PCM downloads and uploads of any type do not appear to be any slower than before.

Also, please note that MP3s of any sampling rate other than 44.1kHz have to be resampled and transcoded [one way or another] before they can be used with HiMD. While yes, this information is in the manual for MP3-capable HiMD units, the most prevalent reference is on the technical specs page and not anywhere that the average user would look. Hence my mentioning it here, since audiobook users tend to gripe about SS's poor handling of their [already specified-as] non-compliant files.

Attempting to download a 48kHz MP3 directly results in the following message from SS:

MP3 files with a non-44.1kHz audio sampling rate will be transferred.

Please note that some devices or medias [sic] cannot support playback for files of this type.

If you cannot play these files with a device, change the transfer settings to Specifed bit rate transfer mode.

MP3s of any sampling rate other than 44.1kHz transferred directly to any MP3-capable HiMD will only result in the message "CANNOT PLAY" on the unit when playback is attempted.

There's [a lot] more relating to this at the bottom under "MP3 transcoding."

* downloading single tracks

<blockquote>Tested with: MP3 @ 192 and 320kbps, as well as VBR files; a3+ @ 192, 256, and 352kbps, also PCM.

No problems experienced regardless of file format [assuming they're compliant].</blockquote>

* downloading multiple groups

<blockquote>Several users have expressed having difficulty doing this with both SS 3.3 and 3.4 already.

Tested with: MP3 @ 192 and 320kbps, as well as VBR files; a3+ @ 192, 256, and 352kbps, also PCM.

No problems experienced regardless of file format [assuming they're compliant], with as many as 10 groups/albums at a time.</blockquote>

* encoding from CD or WAV files

<blockquote>I tried this with 192 and 352kbps a3+ modes, with "high quality" option enabled.

No problems whatsoever experienced. In particular, no misplaced/moved trackmarks [tested with self-made mix CDs with segueing tracks and Pink Floyd's Dark Side of the Moon] and no level differences between channels.

I'll note that encoding from both 16- and 24-bit WAV files @ 44.1kHz and 48kHz sampling rates works fine. See below for the reasons why I verified this.</blockquote>

* MP3 transcoding

<blockquote>Lots of issues here. This is probably the single most important downloading-related issue for netMD and HiMD users, so please read the whole thing.

I digress! Sony have made me a liar by downgrading SS! Using FFDshow with 24-bit output, SS 3.4 ends up with 0-length OMA tracks. This is very odd, because it used to work just fine this way, though admittedly I haven't transcoded any MP3s with SS since v3.1.

Using FFDshow with 16-bit output, everything works. Almost.

From 44.1kHz sampling-rate files, SS transcodes just fine.

From 48kHz files [which most will never encounter] the transcoded output is wracked with severe aliasing distortion. Changing the active codec on my system to FhG's [as well as switching between libmad and mp3lib in FFDshow] does not affect this; the aliasing distortion is still present, and HIGHLY audible in either case. To those who don't know what aliasing distortion is, it sounds like high-pitched [harmonic] buzzing.

This also seems odd to me, because I had transcoded 48kHz MP3s with SS in the past [with FFDshow in 24-bit mode, no less] with no ill effect. It's even more odd to me, since encoding 48kHz WAV files, which also get resampled, works perfectly fine.

For all intents and purposes, it's safe to say that at this stage SS can ONLY accept 16-bit, 44.1kHz input from any MP3 codec. Whatever resampling method SS is using internally is obviously NOT working at all when the data is coming from a directshow MP3 codec.

As SS has already been known to have problems - regardless of what MP3 codec you're using - with sampling rates other than 44.1kHz, I can only recommend to anyone wanting to transcode MP3s in any rate other than 44.1kHz to resample the tracks in question before attempting to do anything with them in SS.

I will suggest two ways to do this: [though these are by no means the only ways possible]

<blockquote>* The first is to decode the non-MD/HiMD-compliant files to WAV and upsample them to 44.1kHz with an editor such as Audacity, or the built-in functions of conversion software such as dBPowerAmp BEFORE doing anything with them in SS. If using editing software, this can be done with mono WAV files, making them 1/2 the size, btw.

* The second is to use FFDshow as your MP3 codec. Note that I do not really advise this for non-technical users as the myriad options it presents may end up being little more than confusing to them.

FFDshow has an internal resampling filter, meaning you can set FFDshow to resample to 44.1kHz and use 16-bit output only, then transcode MP3s of any sampling rate in a single step without having to resort to WAV files, external editors, or other conversion software at all.

For users with collections of audiobooks, this may be the most attractive method to convert your low-bitrate, low-sampling rate [i.e. non-MD/HiMD-compliant] MP3s in a single step without having to worry about disc space and/or extra processing time.

Note that if you do use FFDshow as your system MP3 codec, and choose to do this for any reason, you should disable resampling when you're done. Normal listening should not involve resampling [particularly since AVI files with interleaved MP3 soundtracks @ 48kHz will experience a performance hit due to the resampler if it's on when it doesn't need to be.].</blockquote></blockquote>

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

I haven't gotten to these yet, but will post again in this thread when I do:

* handling of tracks that have been edited on the unit [known problem]

* exact behaviour of SS regarding attempts to upload non-DRM'd tracks from different sources

* for sh*ts and giggles, seeing if split WAV files that comply to 75fps lengths remain gapless after encoding to a3+

Link to comment
Share on other sites

Thanks Dex for that thorough investigation!!! B)

I haven't done too much testing on my part, but from what I have done so far (uploaded a few PCM and HiSP recordings), I haven't ran into any issues.

EDIT: (for sh*ts & giggles)

I just opened a WAV file in GoldWave and split the file into 10sec segements using CD compatible WAV format and alignment, then imported these tracks into SonicStage and transferred to my Rh10 in Atrac3+ (352, 256, & 192) and the result was smooth playback without any gaps/pops/clicks whatsoever. :)

These Atrac3+ tracks also playback gapless in My Library after being transferred back from my Rh10 to PC.

Creating an audio CD with SonicStage from the Atrac3+ tracks that were uploaded from HiMD results in a perfect gapless track. However, when the uploaded tracks are then converted back to WAV via SonicStage and burned to an audio CD with Nero, there are gaps/pops.

Hope this helps.

Edited by raintheory
Link to comment
Share on other sites

Great post Dex, thorough, clear and with some pretty conclusive results. Like raintheory I haven't done too much testing with 3.4, just some basic uploading of PCM / Hi-SP and a lot of downloading at various Atrac3+ bitrates (mainly from ripped CD's), but like both of you I have not run into any issues whatsoever either.

Link to comment
Share on other sites

For the record, contrary to chris g's assertions that the codec in SS 3.4 has issues regarding left-right playback balance, after multiple encodings and transcoding [and yes, I listen to the encoded material] I have yet to experience any such issue myself.

I will also add to this to say I have a done a couple more tests with the balance issue and either with ripped cd's or transcoded MP3 files (at multiple bitrates) converted and then transferred or converted "on-the-fly" as part of the transfer I cannot substantiate any claims of one channel being "louder" or significantly different than the other. These were also compared with encodings of the same cd albums made with 3.3 before I upgraded and again no difference.

As for the multiple groups transfer again no issues transferring multiple groups of ripped cd's or transcoded MP3's. Also no issue transferring multiple groups of MP3 natively to DH10P or multiple groups of MP3 and converting on the fly to Atrac transferring to NH1.

NB: all MP3 transcoding was from 44.1kHz sample rates in the original files.

Link to comment
Share on other sites

Here's what may seem an odd request to those of you reading this:

Look at the list of tests I did. Most don't take very much time to repeat. If you have the time, please check out that these things work in your current installation [regardless of SS version].. then post here whether everything passed or not [including your version info, of course].

The reason I'm asking this is simple: there are lots of questions and complaints about SS of any given version not working correctly. Usually they are reported by only one [person] or a couple of people.

By comparison, almost NO ONE reports when SS is working just fine. As a result, the forum is loaded with people making complaints, with only the brave few of us who ever say "It's working ok for me."

So please - if you have a few minutes, even just to reproduce a couple of the above tests - PLEASE DO SO and report on your results. It would be quite useful to know if there are more people out there for whom everything works OK. It might also help to narrow down [if we report other info like what our installed MP3 codec is, SS module versions, basic system specs et al] the causes of some of the more obscure problems [i.e. most of them] that people have with SS.

Thanks, everyone.

Oh, and perhaps one of the mods could temporarily [for a month perhaps] pin this thread so it's easy to find. Just a request, mind you.

Quick edit:

Many of us, myself included, have been complaining for a long time about Sony's apparent lack of real-world usage testing and their indisputable total lack of any kind of a public bug-reporting mechanism.

Let's face it: WE ARE the usage testers. As such, and since SS is the ONLY choice in software for us to use, really - it would be helpful in the extreme both to us as users and Sony as the company making the software if we actually did report usage info such as reproducable crashes and known software [especially audio codec] conflicts - as well as when it just plain works as it's designed.

Link to comment
Share on other sites

Creating an audio CD with SonicStage from the Atrac3+ tracks that were uploaded from HiMD results in a perfect gapless track. However, when the uploaded tracks are then converted back to WAV via SonicStage and burned to an audio CD with Nero, there are gaps/pops.

You have set Nero to DAO (DiscAtOnce)-Mode?

@Dex: Thanks for testing.

Since I don't use MP3, the behaviour on MP3-import is not an issue for me.

Oh, and SonicStages MP3-Encoder still sucks like a black hole. Use LAME instead.

Edited by jadeclaw
Link to comment
Share on other sites

You have set Nero to DAO (DiscAtOnce)-Mode?

@Dex: Thanks for testing.

Since I don't use MP3, the behaviour on MP3-import is not an issue for me.

Oh, and SonicStages MP3-Encoder still sucks like a black hole. Use LAME instead.

Yep, DAO. a no-go.. ;)

On another note:

Did some testing regarding MD5 and CRC values of WAV files that are transferred to HiMD then back to PC. Also did said testing with some mp3 files on my RH10.

Results:

WAV files retain their information perfectly. MD5 and CRC32 values are identical before and after transferring.

However, interestingly enough mp3 files that are transferred as-is to my RH10 have different MD5 and CRC32 values after being transferred back. Personally I find this a little odd considering SonicStage does not appear to be converting these mp3's at all, it seems the recorder is doing something to the data. Seems kind of fishy considering the whole lackluster native mp3 playback on the 2nd gen units... <_<

EDIT:

Just tested the same with an Atrac3+ file 192kbps... MD5 and CRC32 values are different as well after transferring back to PC. I tagged the file to take into consideration the fact that SonicStage will write album info as "imported from HiMD" if there is no album information listed. So now I'm wondering what info is being added/changed in these files that isn't happening with the WAV files...

Edited by raintheory
Link to comment
Share on other sites

raintheory: interesting find. It would be harder to do with the OMA tracks, but have you tried stripping the MP3s of tags -completely- before and after the hash checks?

And how's this for a nutty thought - what if the MP3 playback "defect" were the most obvious watermarking scheme ever implemented?

Have you -listened- to the MP3s after upload? Do they sound the same?

Must try this myself.

Link to comment
Share on other sites

Just tried the stripping of tags prior to and after transferring... (Transferred mp3 as-is to RH10)

Noticed that the file size is slightly less after the transfer, and the header is moved... Therefore, obviously the MD5 and CRC32 values are changed.

Before Transfer:

Size: 11526811 bytes

Header found at: 1040 bytes

Length: 480 seconds

MPEG 1.0 layer 3

192kbit, 18411 frames

44100Hz Stereo

CRCs: No

Copyrighted: No

Original: No

Emphasis: None

After Transfer:

Size: 11525643 bytes

Header found at: 0 bytes

Length: 480 seconds

MPEG 1.0 layer 3

192kbit, 18411 frames

44100Hz Stereo

CRCs: No

Copyrighted: No

Original: No

Emphasis: None

Edited by raintheory
Link to comment
Share on other sites

Concerning comparing mp3's... For genuine results convert mp3 to wav before and after dl/ul and compare the wavs.

WAVs can also contain some meta-info, so to compare them rightly some meta-aware tools should be used. I've heard CDex can do the job

I've done this testing while converting the mp3's to WAV before and after as well. Same result. <_<

If you have the means, please test this as well though, ^_^

Link to comment
Share on other sites

... Cont'd from initial post

Hmmm.

Making the disc to try uploading unit-edited tracks from .. ran into something I'd never noticed before: [noting this is with an RH10]

If attempting to move a track on a HiMD disc, you can move it from group to group, or outside of groups, but not within its original group.

I don't know about you, but this seems a bit fishy to me.

The following test is affected by this.

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

* handling of tracks that have been edited on the unit [known problem]

Bear with me on this one. There were complications.

<blockquote>Conditions:

<ul><li>Recorded 3 tracks in HiSP mode on 1GB disc. Tracks were 5, 25, and 5 minutes in length.</li><li>Split the 25-minute track on the recorder into 5 minute, 1 minute, 30 second, 1 minute, and 17:30 tracks.</li><li>Moved the tracks around outside their original group into no particular order.</li><li>Plugged into computer. SS reads, "Cannot read this disc .. possibly initialised by another progrem .. re-initialise the disc to use it."</li><li>Pressed STOP, resulting message was "DISC ERROR"; ejected the disc. Re-inserted it and closed the unit.</li><li>SS responds with same error message again.</li><li>Pressed STOP, same message showed on RH10 display, unplugged USB cable to unit [charged battery was in unit].</li><li>Plugged back in, SS came up with the contents of the disc with no further problems.</li><li>Moved all tracks back into the group in same [edited] order they were on disc.</li><li>Uploaded all tracks to computer with no problems. All tracks are playable.</li></ul>

<blockquote>

This was obviously not a very rigorous test, just seeing if the basics work, which they do. If anyone out there wants to invest the time to record something long, split it up into a lot of tracks and rearrange their order on the recorder itself, adn see if SS still uploads properly .. especially if more than one stop/start was made during recording.. then the time would be appreciated.

At the very least, this simple test suggests that the "edited on unit" bug may be fixed [assuming it ever would have happened with my installation].

It also suggests that the dreaded "re-initialise your disc" error might be reversible by unplugging one's HiMD and/or ejecting the disc, and possibly also removing the battery while doing so [something I didn't have to resort to, but you never know - forcing a "cold reboot" by removing all power does fix some issues that appear unrecoverable when they actually are].

I forgot something in there...

in between "Pressed STOP, same message showed on RH10 display, unplugged USB cable to unit [charged battery was in unit]."

.. and .. "Plugged back in, SS came up with the contents of the disc with no further problems."

There should be another line:

*ejected disc, reinserted it and closed unit, played disc on unit to verify it still held its previous contents, which it did.

Link to comment
Share on other sites

Another interesting find as regards MP3 handling:

Audiobook users perk up your ears: I just dl'd a CBC radio documentary which is a 96kbps *mono* encoded mp3 with a sampling rate of 44.1kHz. It transferred fine to my RH10 and plays just fine as well.

This means at least a couple of things, for thoe of you who hate wasting the space on transcoding and processing recordings such as audiobooks and radio broadcasts [i.e. voice]..

* as long at the sampling rate is 44.1kHz, you can probably go all the way down in bitrate to the lowest standard [MPEG-1, layer 3, not MPEG-2, layer 3] .. which if I'm not mistaken is 32kbps..

* mono recordings play just fine, so there's no need to waste space on extra bitrate for another [redundant] channel .. or ..

* in the case of joint-stereo recording, space wasted on extra fidelity in the 'm' channel where it doesn't really need it

* which means that transcoding low-bitrate mono mp3s to a3+ 64kbps or 48kbps [HiLP], whether they go into the a3+ encoder as dual-mono or true mono [the encoder, being joint stereo, sees both as the same thing] you should get good results

Just thought people might like to know that.

BTW, if there's demand for a HOWTO on using FFDshow to transcode MP3s of sampling rates other than 44.1kHz [which would include many radio programs and audiobooks], in a single step using SS only and without using any WAV files, I will make one.

And yes, I know I have the lowest standard 44.1kHz/mono mp3 bitrate wrong [i think it's actually 56 or 64kps, whatever.]

Another d'oh: the bitrate of that CBC radio MP3 is 56kbps, not 96kbps.

Link to comment
Share on other sites

Just tried the stripping of tags prior to and after transferring... (Transferred mp3 as-is to RH10)

Noticed that the file size is slightly less after the transfer, and the header is moved... Therefore, obviously the MD5 and CRC32 values are changed.

Before Transfer:

Size: 11526811 bytes

Header found at: 1040 bytes

Length: 480 seconds

MPEG 1.0 layer 3

192kbit, 18411 frames

44100Hz Stereo

CRCs: No

Copyrighted: No

Original: No

Emphasis: None

After Transfer:

Size: 11525643 bytes

Header found at: 0 bytes

Length: 480 seconds

MPEG 1.0 layer 3

192kbit, 18411 frames

44100Hz Stereo

CRCs: No

Copyrighted: No

Original: No

Emphasis: None

You could always try to re-transfer the same tracks (the one's you re-upped, not the originals :)) one more time and check if they will change somewhat every time or only after the first transfer

Link to comment
Share on other sites

You could always try to re-transfer the same tracks (the one's you re-upped, not the originals :)) one more time and check if they will change somewhat every time or only after the first transfer

Just checked this and the mp3 is indeed slightly smaller again after a subsequent transfer.

I also inverted the phase of the original and mixed it with the uploaded track and the phase inversion shows no difference at all in the signal... ???

Please if someone else could test this I would greatly appreciate it. ^_^

Link to comment
Share on other sites

I just opened a WAV file in GoldWave and split the file into 10sec segements using CD compatible WAV format and alignment, then imported these tracks into SonicStage and transferred to my Rh10 in Atrac3+ (352, 256, & 192) and the result was smooth playback without any gaps/pops/clicks whatsoever. :)

These Atrac3+ tracks also playback gapless in My Library after being transferred back from my Rh10 to PC.

I tried this same thing with a previous version of SS (can't remember exactly which one) and the songs had gaps on it. So this is a a improvement i think. :ok:

Edited by sebastianbf
Link to comment
Share on other sites

  • 2 weeks later...

I tried this same thing with a previous version of SS (can't remember exactly which one) and the songs had gaps on it. So this is a a improvement i think. :ok:

Well for me it's not recoganising one of the Samsung DVD/CD Writers moidel: SH-W162C

which does annoy me when I need to write atrac cds for my walkman, anyone know if this is a bug or not?

Link to comment
Share on other sites

  • 1 month later...

I just got my first real issue with SonicStage (3.4) today. I was uploading a live recording (swedish band In Flames), and I got a pop-up error message that it could not transfer the track and that the connection with the HiMD was lost. Quit SonicStage, close the device (with the icon next to clock, using XP SP2 with all patches) and now the media is unreadable, my NH900 ask to format it every time now ...

First time that I ever have this happening, but it stills possible to corrupt an HiMD during upload.

Link to comment
Share on other sites

  • 1 month later...

OK, I wanted to add a music CD to one of my 1GB minidiscs that I had ripped using Windows Media Player. The files were encoded as MP3 at 192kbps, but when I try to import the songs SonicStage 3.4 locks up. I have attempted a uninstall>reboot>reinstall of the program, but it is still locking up on me when I do an import. I dont know what has caused it not to work because it was working before just fine, I have uninstalled any software that I installed after SonicStage 3.4 but that hasn't eased my pain any.

I am new to Minidics and SonicStage, so please be gentle.

I have searched Google for any hope of a answer but most of them point to the 3.4 version as a fix.

Thanks,

Link to comment
Share on other sites

I am new to Minidics and SonicStage, so please be gentle.

I have searched Google for any hope of a answer but most of them point to the 3.4 version as a fix.

Post a new thread in the software support forum, and please read and follow the forum guidelines for posting beforehand.

Link to comment
Share on other sites

This isn't a question for this thread, since it has nothing to do with this thread. Please post such questions in software support in the future.

Short answer: CD importing *should* bring tracks into the SS library in order. If you open the album in the albums view and tracks are randomly ordered, just click on the column header for "track number" .. this will force it to re-sort the album. Clicking once will sort one way [ascending or descending] and clicking it again will do the opposite. Do it once or twice depending on which way it sorts first. Downloading the album after re-sorting should put the tracks in correct order on your MD/HiMD.

As for albums already downloaded, you'll have to sort them manually.

Link to comment
Share on other sites

I'll say this again, just so it's clear:

This is not a support thread. Do not post your questions here. There's a reason why we have a software support forum.

If you have specific info about SS's uploading or downloading behaviour, feel free to add it here. Please do test things [at least minimally, as I did] to make sure that a particular behaviour is consistent.

Link to comment
Share on other sites

I finally got SS to demonstrate it's "transfer quantity" bug for me. Yeehaw.

I think it's because of something else I'm running at the same time, so I'm trying to figure out which soft it is.

With OMA [atrac3/atrac3plus] tracks, there is no problem.

With MP3s, a maximum of 32 tracks can be dropped onto the HiMD at a time. This is odd, because I have done this [120+ tracks at once] before without incident. Hence thinking it's caused by something else that's running.

If I figure out which soft is causing the problem, I'll post it here.

Link to comment
Share on other sites

  • 2 weeks later...

1. Concerning mp3 conversion problems.

Since I installed version 3.4 (and now still with 4.0), mp3 conversion doesn't work anymore.

I can play mp3s from within SS, and when I choose libmad or mp3lib in ffdshow (version of may 2006), I can see that ss uses ffdshow because the tray icon shows up. If i choose "disable" that tray icon doesn't show up.

When I try to convert a track it ALWAYS gives me the error:

Cannot Convert the specified track.

Possible reasons may include:

- The track (files) cannt be found.

- SS does not support the file format.

- The track is copyrighted.

(00000000)

Some people blamed some other installed codec for this, but I didn't find what causes the trouble on my system yet. The problem is only on my laptop.

2. Concerning upload problems

When I uploaded my own mic recordings in SS 3.4, it didn't create nice filenames anymore (sometimes it did), but just took trackname, and (almost always) artist and album from some random other (mp3) file in my library, so that it was almost impossible to find the recordings after uploading. It seems to be fixed in version 4.0.

Very strange... Was I the only one having this problem?

Link to comment
Share on other sites

Since I installed version 3.4 (and now still with 4.0), mp3 conversion doesn't work anymore.

I can play mp3s from within SS, and when I choose libmad or mp3lib in ffdshow (version of may 2006), I can see that ss uses ffdshow because the tray icon shows up. If i choose "disable" that tray icon doesn't show up.

Make sure [if you're using FFDshow with SS] that FFDshow [on the "Output" page] is set to use 16-bit output ONLY [by default, all bit-depth boxes are usually checked and this should work - but if you force it to use a higher bit-depth by deselecting 16-bit, it WILL NOT work with SS], and that the "Connect to" dropdown is set to "any filter" [since SS is neither a directsound driver nor a waveout device].

When I uploaded my own mic recordings in SS 3.4, it didn't create nice filenames anymore (sometimes it did), but just took trackname, and (almost always) artist and album from some random other (mp3) file in my library, so that it was almost impossible to find the recordings after uploading. It seems to be fixed in version 4.0.

Very strange... Was I the only one having this problem?

I can only tell you it wasn't doing that here.

Link to comment
Share on other sites

Make sure [if you're using FFDshow with SS] that FFDshow [on the "Output" page] is set to use 16-bit output ONLY [by default, all bit-depth boxes are usually checked and this should work - but if you force it to use a higher bit-depth by deselecting 16-bit, it WILL NOT work with SS], and that the "Connect to" dropdown is set to "any filter" [since SS is neither a directsound driver nor a waveout device].

I (forgot to mention it, but I) did all that.

It's not some obvious settings issue, since I thoroughly checked and tried out all these different options.

It feels to me as if some other DS filter misbehaves or was not uninstalled cleanly...

Link to comment
Share on other sites

I (forgot to mention it, but I) did all that.

It's not some obvious settings issue, since I thoroughly checked and tried out all these different options.

It feels to me as if some other DS filter misbehaves or was not uninstalled cleanly...

Is it still doing it with SS 4.0? And what specific version of FFDshow are you using?

Also - are you repeatedly trying to transcode the same tracks? I had SS 4.0 cack due to an error of my own [specifically, not switching FFDshow to 16-bit output] while testing [the night it came out] .. SS left invalid links in its Db to nonexistent OMA tracks [the transcoded ones that failed] which prevented those MP3s from being transcoded until I manually deleted the links [in the track properties]. Doing a database "optimisation" may possibly be another way to fixed that [since it should remove the invalid entries].

Link to comment
Share on other sites

Is it still doing it with SS 4.0? And what specific version of FFDshow are you using?

It's still doing that.

FFDShow May 22 2006 SSE (and 2 or so earlier versions since jan 2006).

Also - are you repeatedly trying to transcode the same tracks?

No.

(Somehow I don't think it's ffdshow causing the trouble. I should uninstall it. Maybe I'll try that later, and post about my findings.)

Link to comment
Share on other sites

Somehow I don't think it's ffdshow causing the trouble. I should uninstall it. Maybe I'll try that later, and post about my findings.

You can find out without uninstalling it.

Go to the "codecs" page in the audio decoder config, and set MP# to "disabled".

Whatever other codec is on your system will then be used by SS. If the problem persists, it's not being caused by FFDshow.

Link to comment
Share on other sites

Already tried that. As I said, I don't think it's ffdshow, but I didn't find out yet what causes the trouble. Uninstalling would make me 100% sure ffdshow has nothing ot do with it.

DirectShowFilterManager, GSpot, GraphEditor all list so much codecs, that I don't know which one could possibly be interfering. I tried changing priorities for some filters but that didn't solve anything yet.

What is strange though is that SS uses ffdshow when playing, but appearently not when transcoding, ... But what does it use? I don't really know how to find that out. I should have a way to monitor SS to see what filter it tries to connect to.

Link to comment
Share on other sites

  • 2 years later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...