Ubuntu
soundconverter package

Sound Converter puts output files in the wrong folder, even overwriting files

Bug #348546 reported by Xero Xenith
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
soundconverter (Ubuntu)
In Progress
Undecided
Unassigned

Bug Description

Binary package hint: soundconverter

Description & Steps to Reproduce:
--Have two or more subfolders in a folder (z). Let's call them x and y. Fill x and y with music.
--Select "Same folder as input file" under "Where to place results?" in Sound Converter Preferences.
--Drag x and y in, and convert to.
--The output will be placed in folder z, not x and y as appropriate.

Worse, if there are similar files in x and y, similar so the output filename will be identical, Sound Converter will simply overwrite the first one for the second.

Expected outcome:
The output files go into the folders the source files were in - in x and y, not z.

Experienced on Jaunty with all latest upgrades, but I expect it to also be in Intrepid (at least).
I realise this may be "functionality": if so, perhaps the option needs renaming?

Revision history for this message
Tony McKenzie (mckenzie-tony) wrote :

What version of soundconverter are you using? I tried this with version 1.4.1 on jaunty with no luck. Is there a specific amount of files that you must try and convert for this to work? I tried your z x y method even naming them the same with a file in each folder and had expected results. Thank you

Changed in soundconverter (Ubuntu):
status: New → Incomplete
Revision history for this message
GautierPortet (kassoulet) wrote :

Can you please run "soundconverter --debug" in a console, reproduce the problem, and paste here the output ?
Thanks for your help !

Revision history for this message
Xero Xenith (xero-xenith) wrote :

My apologies! I remember getting very frustrated by this bug when converting generically named tracks (Track 01.mp3), but I can't seem to reproduce it on the latest updates as of now - perhaps it's been fixed upstream?

I'll do a few more tests - In any case, I'll be sure to report back if I experience it again (with a debug log).

Revision history for this message
Waldir Pimenta (waldyrious) wrote :

This happened to me too, but it was because I chose a custom filename pattern for the output file. The path prefix for that option is set to the folder you choose to open, instead of the corresponding subfolder for each file. The overwriting also happened, because I had files without metadata (title=unknown) and the output filename ended up being the same for several different input files. I think I should at least have got a warning that it was about to overwrite the files.

So, maybe this was your problem too? If not, this should probably be added as a separate bug.

Revision history for this message
Xero Xenith (xero-xenith) wrote :

It's possible; I wiped many config files on updating from 8.10 to 9.04, which would have removed any custom pattern and would have 'fixed' the problem for me, if what you say is true... could somebody confirm? (I'm at work at the moment, I should find time to test when I get back.)

Revision history for this message
Stefan Friesel (stefan-friesel) wrote :

This bug still exists in jaunty and upstream, but instead of overwriting SC claims it cannot read the input file that would overwrite another. Steps to reproduce:
- In Settings: same folder as source, file name something else than "as source" e.g. "number - title"
- Now add folder hierarchy as described in OP

The files are now placed in z/, not z/x/ and z/y/

Changed in soundconverter (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Stefan Friesel (stefan-friesel) wrote :

This patch against 1.4.4 uses the actual file path if "same folder as source" is selected and create subfolder is not selected.

Changed in soundconverter (Ubuntu):
status: Confirmed → In Progress
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.