Topic: iPod workflow for parallel APE and MP3 (Read 10401 times)

noborg · « **on:** March 12, 2003, 06:11:19 pm »

I'm converting from MJ8 to MC9. I've been using the iPod with MM, on a directory structure that mirrors my MJ8 (now MC9) structure. I used MJ8 to reformat from ape to mp3. (Is that what is being called "transcoding", or does that term perhaps imply some on-the-fly recoding when uploading?)

What's the best way to manage this in MC9? For example, should I keep the mp3 files in a separate MC library or should I import them into my existing library? Is there an elegant way to maintain only one set of playlists and have them work both on the PC (ape files) and on the iPod (mp3 or whatever I end up using)?

I'm sure there are other issues as well. I would appreciate advice.

Thanks.

js

SteveG · « **Reply #1 on:** March 13, 2003, 05:09:39 am »

js,

The term transcoding in the iPod thread has been used to mean converting files from one file type/bitrate to another. In regards to the iPod, you can transode files on the fly when transfering to the iPod. The downside to this, is that it is time consuming to decode and reencode the files whenever you transfer them. If you have the space on your PC, it might be better to convert the files to whatever format/bitrate you want for the iPod and then create smartlists that handle these files. If you do this, when you want to transfer files to the iPod you can choose to synchronize the playlists that you want and the transfers will be very fast.

Steve

noborg · « **Reply #2 on:** March 13, 2003, 05:29:09 am »

Thanks Steve,

I was in fact planning to maintain a separate set of iPod files (i.e., not convert on the fly). But do you suggest keeping those files in a separate library? Or would it be better to tag them with a custom field (can that be done during transcoding?) and use that field (or perhaps bitrate/format) as smartlist criteria?

js

bspachman · « **Reply #3 on:** March 13, 2003, 06:13:16 am »

Quote

Thanks Steve,

I was in fact planning to maintain a separate set of iPod files (i.e., not convert on the fly). But do you suggest keeping those files in a separate library? Or would it be better to tag them with a custom field (can that be done during transcoding?) and use that field (or perhaps bitrate/format) as smartlist criteria?

I wanted to chime in and say I love this thread! I think a 40GB iPod will be in my future, so this will become an issue. I've already started transcoding my APEs to MP3 so I can stream them wirelessly from my music server to my Mac (I just use iTunes to point at the transcoded folder on the server).

I'm also wondering which "flavor" or iPod to go for. I can add FireWire to the music server and do everything from Windows & MC pretty easily, but I already have FireWire capability on my Macintosh....any thoughts here? (I can always hook the Mac up to a 100BT network for transfers when going from the music server to the iPod--I'm not limited to wireless speeds...)

Brad

Kurt Young · « **Reply #4 on:** March 13, 2003, 06:30:17 am »

Here's one thing that I do that you can adapt to your own needs:

I have a smartlist called "iPod Tunes" -- it has only one rule: "Keywords contains iPod".

When I say to myself "I want to make sure that this music is always on my iPod" I just add the word iPod to the song's keywords field. This makes it show up on my iPod Tunes smartlist, and I just make sure that this smartlist is included when I do a sync. Kind of a "loader list"

noborg · « **Reply #5 on:** March 13, 2003, 06:44:57 am »

Brad wrote (P.S., how do you do those blue-box quotes?):

"I'm also wondering which "flavor" of iPod to go for. I can add FireWire to the music server and do everything from Windows & MC pretty easily, but I already have FireWire capability on my Macintosh....any thoughts here?"

If you go with a Mac iPod 9 (assuming that's what you mean by "flavor") then wouldn't you have to load it via iTunes? If so, you might not be able to take advantage of MC smartlists, and you might end up doing double-duty on file management.

js

SteveG · « **Reply #6 on:** March 13, 2003, 07:09:58 am »

js,

I like Kurt's suggestion. Although the library idea could work if that seems better for you.

Steve

noborg · « **Reply #7 on:** March 13, 2003, 09:16:42 am »

Yes, the "ipod" keyword (with variations) is a good idea if using one combined library.

Regarding the approach of having a separate iPod (mp3) library:

1. How can I transfer a playlist from one MC library to another -- I tried "export playlist" followed by "import media", but the result is that the ape files from my original library are imported into the mp3 library. I just want to transfer the list of songs. There doesn't seem to be an "import playlist".

2. How can I transfer (export/import) a smartlist from the ape library to the mp3 library?

js

SteveG · « **Reply #8 on:** March 14, 2003, 05:25:54 am »

js,

I think I have a better way for you to come at this. It involves waiting for the next build. What you should do is create one library, then use the view filter which will allow you to switch from a view that is .ape only or .mp3 only. This already works in what you have, but it does not work for smartlists, but will in the next build. In case you are unfamiliar with it, when applied, it filters your library so that you only see certain filetypes.

This is the way to go so that you don't have to copy and move playlists, you will just create them once.

In answer to your questions, when you export a playlist, make sure you do it as an mpl. For smartlists, you would need to cut and paste the text from the filter line.

noborg · « **Reply #9 on:** March 14, 2003, 12:40:09 pm »

Thanks Steve,

By "view filter", do you what's called "view scheme" in the current interface, or perhaps something else? I don't quite see how this solves the problems, but I'll wait and check out the next build.

Regarding importing/exporting playlists, if I export an a playlist from my ape library as mpl, the import to a different library still results in importing the corresponding ape files. I just want to import the list of songs and use that as a playlist in the mp3 library.

Stated differently, playlists appear always to be lists of files and not lists of songs. Have I missed something?

js

SteveG · « **Reply #10 on:** March 14, 2003, 01:03:49 pm »

js,

View Filter should be in the Toolbar in the latest build. If not, right click on the toolbar and add it as an available toolbar button.

I think this is the way to go for you.

Steve

noborg · « **Reply #11 on:** March 17, 2003, 05:02:13 am »

Hi Steve,

Indeed that does seem like the way to go – quite elegant in fact (with one missing piece). To recap:

1. transcode all ape files to mp3 or other lossy format (for convenience and safety, placed in a separate directory tree)

2. import the mp3 files into the same (initially ape only) library;

3. define ape and mp3 smartlists respectively with the single rules "File type: ape" and "File type: mp3"

4. when playing files on the PC, set the filter view to ape; then all other smartlists will resolve to the ape versions;

5. when synchronizing with the ipod (or other portable), set the filter view to mpe; then all other smarlists will resolve to the mp3 versions;

The missing piece concerns playlists (as opposed to smartlists). It appears that playlists are in effect lists of files rather than lists of songs. So when you create a playlist (e.g. by drag-and-drop) you get a specific file (ape or mp3). What's needed is a way to have a playlist that behaves like a smartlist as above.

In fact, a smartlist can do that by having rules that select the artist/song pairs, but it's labor-intensive to create them. Ideally, one would like to drag a song and drop it onto a smartlist, but MJ currently doesn't permit that, perhaps because the desired semantics are not obvious.

All this leads to the following suggested modification:

Enable drag-and-drop of single songs into smarlists, with the result that a rule is created for the given album, artist, and name.

A more elaborate interface could include an option screen where one could define which fields turn into smartlist rules, but I believe that the above default would by itself suffice.

Thanks for your help and consideration.

js

SteveG · « **Reply #12 on:** March 17, 2003, 06:15:27 am »

js,

Thanks for the comments and suggestions. The problem I see with your suggestion, is that smartlists are actually a set of filters that exclude files based on rules. If you were to have a filter created based on the drag and drop of a particular file, it would end up subtracting anything in the smartlist that was not compatible with it's rules. I hear your critique that you want the ease of use of Playlists but the control of smartlists. Let us stew on this and try to come up with improvements to satisfy this.

Thanks,

Steve

paulj · « **Reply #13 on:** March 17, 2003, 07:45:32 am »

Quote

Hi Steve,

1. transcode all ape files to mp3 or other lossy format (for convenience and safety, placed in a separate directory tree)

2. import the mp3 files into the same (initially ape only) library;

I've also been trying to find the best way to manage this.

I'd like to see 1 & 2 combined into one step...

When you 'Convert to another format', the options include 'Update Library' and 'Delete Original'. The way this should work is:

Update Libary: CHECKED
Delete Original: CHECKED
= replace the ape with the newly encoded MP3

Update Libary: CHECKED
Delete Original: UNCHECKED
= Add the newly encoded MP3 to the libary but leave the ape there also.

The first example works like that now. The second example works similarly, but does not delete the ape from the disk. It is still removed (replaced) from the library however. It would make more logical sense to me if it were to simply add the MP3 and leave the ape alone.

SteveG · « **Reply #14 on:** March 17, 2003, 08:01:48 am »

Update Libary: CHECKED
Delete Original: UNCHECKED
= Add the newly encoded MP3 to the libary but leave the ape there also.

"The second example works similarly, but does not delete the ape from the disk."

I don't follow. By unchecking "Delete Original" the file is not to be deleted. This seems like the expected behavior. I must be missing what you are saying. Can you explain again?

Steve

noborg · « **Reply #15 on:** March 17, 2003, 11:07:33 am »

I believe Paul's point is that in the second example you have to follow the transcoding operation with an import operation, which is somewhat cumbersome. It would be nice to have an option where the file is transcoded and both files end up in the database.

Thanks for pointing out the flaw in my suggested playlist solution. I forgot that a smartlist logically ANDs the component rules -- indeed, I find this problematic. I guess it would be too hard to have a general AND/OR structure, but that in fact would solve the playlist problem and make smartlists far more general.

In any case, I look forward to your thoughts on this.

A related point: in the ipod support thread it was implied that transcoding will not take place unecessarily, but I don't see that behavior. If I select a file for transcoding (converting) that has already been transcoded in exactly the same way, the transcode still happens and a new (identical except for name) file is written. Did I miss something? If not, a simple solution would be to add an option "do not convert if file exists". (This would be very helpful when wanting to update my mp3 files to keep them parallel to the ape files.)

Thanks

js

paulj · « **Reply #16 on:** March 17, 2003, 11:19:43 am »

Quote

I believe Paul's point is that in the second example you have to follow the transcoding operation with an import operation, which is somewhat cumbersome. It would be nice to have an option where the file is transcoded and both files end up in the database.

Yep, that's what I meant to say.

SteveG · « **Reply #17 on:** March 18, 2003, 05:53:25 am »

Quote

I It would be nice to have an option where the file is transcoded and both files end up in the database.

We can add this at a later time. It is not a trivial change.

Quote

If I select a file for transcoding (converting) that has already been transcoded in exactly the same way, the transcode still happens and a new (identical except for name) file is written.

I cannot duplicate this. I took an .mp3 file encoded at 128 kbps and put it in the upload queue. I selected "Options" and checked the box to "Force Conversion" My settings were for .mp3 and 128kbps. When I uploaded the file, the transoding box popped up but skipped the file and then transferred. Can you try to follow the steps I did and see if it still fails?

Steve

noborg · « **Reply #18 on:** March 18, 2003, 08:23:07 am »

Steve,

Sorry Steve. I used the wrong terminology and misled you. I was using reformat and transcode as synonyms but I guess that's wrong. I'm still not certain how you use these words, but for my purposes here I'll define:

convert format: convert from one file format to another (e.g., ape to mp3) with results going to a disk file (MC "convert format" command)

transcode: reformat on-the-fly when uploading to the iPod or other portable

The problem I tried to describe arises in steps 1 and 2 of the workflow I described on 17 March, which I rephrase here:

1. Convert format of all ape files to mp3 or other lossy format (for convenience and safety, placing the resulting reformatted files in a separate directory tree)

2. Import the mp3 formatted files into the same (initially ape only) library;

The problem is in step one. Without a "don't overwrite existing files" option, I have to make sure that I select only new ape files for conversion. This is cumbersome and error-prone.

js

SteveG · « **Reply #19 on:** March 18, 2003, 08:56:00 am »

js,

Let me try to understand your concern. You want to maintain a library that has .ape files and copies of these files as .mp3 for your iPod. You can convert your .ape to .mp3 fine, but the problem arises as you add files and then are not sure which have been converted and which are yet to be converted.

Is this accurate?

If so, would it work to check the recently imported smartlist and then convert only the files that have been added?

noborg · « **Reply #20 on:** March 18, 2003, 09:04:36 am »

Hi Steve,

Yes, that's accurate.

Your suggested use of the "recently imported" smartlist is on target, but I think it's more of a partial workaround than a solution. Depending on the frequency of importing and the frequency of converting, I would still have to watch out for files that I have imported recently but already converted.

I still think the right solution is a "don't convert if file exists option" (or perhaps the same logic that's used in deciding whether or not to transcode when uploading).

Thanks for your continuing consideration.

js

SteveG · « **Reply #21 on:** March 19, 2003, 01:00:22 pm »

js,

I will look at improving this tomorrow.

Steve

SteveG · « **Reply #22 on:** March 20, 2003, 06:39:19 am »

js,

I added an option to the converter in MC that will skip files if they already exist in MC's library and if they are the same bitrate. This is now consistent with how the conversions are done during transfers to portables.

Could you please try it out and let me know if it is what you are after?

Thanks,

Steve

noborg · « **Reply #23 on:** March 20, 2003, 03:58:53 pm »

Hi Steve,

Thanks for working on this.

Perhaps I don't understand the new "skip duplicates" option, but I couldn't get it to work (MC 9.0.132).

I converted an ape file to 128 bps mp3 (NOT VBR), imported the new mp3, and then converted the original ape file again. The "skip duplicates" option appears to have no effect (file converted again). I tried this for two cases: converted mp3 written in the same directory as the ape file, and converted mp3 written elsewhere (the way I would operate). Same behavior in both cases.

Please let me know if I misunderstood something.

Also, I'm a bit unclear about the intended semantics for "skip duplicates". You said that conversions would be skipped if they already exist in MC's library and if they are the same bitrate. Would this work properly for mp3 VBR?

js

SteveG · « **Reply #24 on:** March 24, 2003, 09:01:39 am »

js,

I modified this again today so it should work as you expect now. Can you test it again when the next build of MC is released?

Steve

noborg · « **Reply #25 on:** March 27, 2003, 03:58:01 am »

Steve,

I tried this again under MC 9.0.134 (with plugin 9.0.08 ) It still does not work.

I converted an ape file to MP3 VBR (normal) twice with exactly the same settings. The second conversion just created another file (adding "(1)" to the file name).

I tried the same thing with MP3 (64). Same results.

js

noborg · « **Reply #26 on:** March 27, 2003, 04:33:36 pm »

Hi Steve,

Steve,

There's a major bug (I think) that affects the workflow we've been developing. To review the workflow:

1. convert all ape files to mp3 or other lossy format (for convenience and safety, placed in a separate directory tree)

2. import the mp3 files into the same (initially ape only) library;

3. define ape and mp3 smartlists respectively with the single rules "File type: ape" and "File type: mp3"

4. when playing files on the PC, set the filter view to ape; then all other smartlists will resolve to the ape versions;

5. when uploading to the ipod (or other portable), set the filter view to mp3; then all other smarlists will resolve to the mp3 versions;

The problem is with step 5, above. With the filter view set to mp3, the files shown in MC are indeed just the mp3 versions of whatever smartlist is selected.

But when I drag that smartlist to the iPod, MC tries to queue both the ape and mp3 versions (with an error message for each ape version).

So the "dragged" smartlist does not take into account the filter view.

yikes

js

==

Media Center Registered 9.0.135 -- C:\Program Files\J River\Media Jukebox\

Microsoft Windows XP Workstation 5.1 Service Pack 1 (Build 2600)
Intel Pentium 4 1893 MHz MMX / Memory: Total - 1047 MB, Free - 523 MB

Internet Explorer: 6.0.2800.1106 / ComCtl32.dll: 5.82 (xpsp1.020828-1920) / Shlwapi.dll: 6.00.2800.1106 (xpsp1.020828-1920)
Shell32.dll: 6.00.2800.1145 (xpsp2.021108-1929) / wnaspi32.dll: Internal ASPI Layer

Ripping / Drive D: Copy mode:ModeSecure CD Type:Auto Read speed:Max
Drive E: Copy mode:ModeBurstBigBuffer CD Type:IDE Read speed:Max
Digital playback: Yes / Use YADB: Yes / Get cover art: No / Calc replay gain: Yes / Copy volume: 32767
Eject after ripping: No / Play sound after ripping: No

Burning / Drive E: LITE-ON LTR-32123S Addr: 0:1:0 Speed:32 MaxSpeed:32 Use MJ Engine:Yes
Test mode: No / Eject after writing: Yes / Direct decoding: Yes / Write CD-Text: No
Use playback settings: No / Normalization: None

SteveG · « **Reply #27 on:** March 28, 2003, 11:25:45 am »

js,

The next build should resolve the first problem you reported. The major problem you report, is indeed reproduceable. It might make in tonight's build. If not, very soon.

Steve

SteveG · « **Reply #28 on:** March 28, 2003, 12:30:01 pm »

js,

The view filter problem should now be fixed (in tonight's MC build). If not, please let me know.

Thanks,

Steve

noborg · « **Reply #29 on:** March 30, 2003, 02:58:08 pm »

Steve,

I'm now running MC9.0.137. I also reinstalled the latest plugin, just to be sure (9.0.09). I don't see any changes, i.e.:

1. a "dragged" smartlist does not take into account the filter view (e.g., when the view is set to "mp3", dragging a smarlist still tries to queue the ape files).

2. when converting formats, the "ignore duplicate files" option does not work;

3. there's no top-level indication of which filter view is currently selected (reported earlier elsewhere)

4. the speed issue discussed elsewhere has not changed (indeed, it seems a bit worse)

Could I be doing something wrong here?

js

SteveG · « **Reply #30 on:** March 31, 2003, 06:56:31 am »

js,

Quote

a "dragged" smartlist does not take into account the filter view (e.g., when the view is set to "mp3", dragging a smarlist still tries to queue the ape files).

This is fixed in the next build. It was some code that did not make it into Friday's build. Sorry.

Quote

2. when converting formats, the "ignore duplicate files" option does not work;

This is fixed in the next build.

Quote

3. there's no top-level indication of which filter view is currently selected (reported earlier elsewhere)

This should be added by the next build.

Quote

4. the speed issue discussed elsewhere has not changed (indeed, it seems a bit worse)

I still cannot duplicate this. If you still see this after tonight, lets post to the iPod thread and ask others if they can reproduce it so we can isolate whether it is something about your individual situation or a broader problem.

Steve

noborg · « **Reply #31 on:** March 31, 2003, 12:25:07 pm »

Quote

> 1. a "dragged" smartlist does not take into account the filter view
>(e.g., when the view is set to "mp3", dragging a smarlist still tries to queue the ape files).

This is fixed in the next build. It was some code that did not make it into Friday's build. Sorry.

This is now working. Many thanks!

Quote

> 2. when converting formats, the "ignore duplicate files" option does not work;

This is fixed in the next build.

This still does not work on my system.

Quote

> 3. there's no top-level indication of which filter view is currently selected (reported earlier elsewhere)

This should be added by the next build.

This still does not work on my system.

Quote

> 4. the speed issue discussed elsewhere has not changed (indeed, it seems a bit worse)

I still cannot duplicate this. If you still see this after tonight, lets post to the iPod thread and ask others if they can reproduce it so we can isolate whether it is something about your individual situation or a broader problem.

This is still a problem. I will test again carefully and post to the ipod thread.

js

===

Media Center Registered 9.0.138 -- C:\Program Files\J River\Media Jukebox\

Microsoft Windows XP Workstation 5.1 Service Pack 1 (Build 2600)
Intel Pentium 4 1892 MHz MMX / Memory: Total - 1047 MB, Free - 104 MB

Internet Explorer: 6.0.2800.1106 / ComCtl32.dll: 5.82 (xpsp1.020828-1920) / Shlwapi.dll: 6.00.2800.1106 (xpsp1.020828-1920)
Shell32.dll: 6.00.2800.1145 (xpsp2.021108-1929) / wnaspi32.dll: Internal ASPI Layer

Ripping / Drive D: Copy mode:ModeSecure CD Type:Auto Read speed:Max
Drive E: Copy mode:ModeBurstBigBuffer CD Type:IDE Read speed:Max
Digital playback: Yes / Use YADB: Yes / Get cover art: No / Calc replay gain: Yes / Copy volume: 32767
Eject after ripping: No / Play sound after ripping: No

Burning / Drive E: LITE-ON LTR-32123S Addr: 0:1:0 Speed:32 MaxSpeed:32 Use MJ Engine:Yes
Test mode: No / Eject after writing: Yes / Direct decoding: Yes / Write CD-Text: No
Use playback settings: No / Normalization: None

SteveG · « **Reply #32 on:** April 01, 2003, 05:11:47 am »

Ignore duplicate files worked for me in the following situation...

Tried to multiple mp3s encoded at 128kbps with the conversion settings set to mp3 128. All files skip as expected. If I include a file of a different type or bitrate, conversion occurs. Can you send me a file that is not being skipped and tell me what settings your converter is set to and I will duplicate and fix the problem? (steve @ jriver.com)

In regards to the top-level indicator, that was supposed to be included yesterday, but the person who was going to do it forgot. It should be in today.

Any more info you can give me regarding a pattern with the speed issue would be helpful.

Steve

noborg · « **Reply #33 on:** April 02, 2003, 05:17:09 am »

Issue: skipping duplicates during convert format

Steve,

It does indeed work for the case you described -- I had been testing other cases that don't work and that made me think it doesn't work at all. Sorry for the confusion.

On my system, "skip duplicates" works if the conversion is to (fixed rate) MP3 provided that the target (post conversion) file is already in the database. It does not work if the conversion is to MP3 VBR, OGG, or various other choices, and it only works if the target conversion is already in the database.

I can guess why the underlying algorithm behaves as described above, but I think that it would be a mistake to have "skip duplicates" work only for fixed-rate MP3. (I happen to use MP3 VBR on the iPod, and in general it's best to have uniform semantics for a global option like "skip duplicates".) Indeed, this is why I had mentioned VBR in earlier posts.

Have you considered handling the option, not by a database lookup, but by checking for file existence? Right now, the behavior is that a new file is created regardless of whether the target file exists -- if there's an existing file, a new one is created with an additional "(n)" suffix. That's fine for the default behavior, but in general it's a bit of a loose end because it creates files that are not consistent with the naming convention selected by the user.

How about renaming "skip duplicates" to "skip if file exists". I think that it would be easy to implement, it would solve the file conversion problem in the context we've been discussing, and it would provide uniform semantics.

js

P.S. The top-level indicator for filter views is there in 140; thanks!

js

SteveG · « **Reply #34 on:** April 02, 2003, 07:57:51 am »

js,

We do not want to customize this algorithm past viewing the information in the database at this time. I currently define a duplicate as any file that has the same name, bitrate and filetype and then skip based on this info. If you want me to define this differently I can. Would you prefer I skip files that have different bitrates? This has negative effects as well?

Steve

noborg · « **Reply #35 on:** April 02, 2003, 01:19:03 pm »

Steve,

I can see why you prefer to keep "duplicates" defined in terms of database criteria. You're right that dropping Bitrate from the criteria has negative effects in some cases, but it's worse to have MP3 VBR and OGG not work at all.

On balance, my suggestion is that you define "duplicate" as having the same database entries for Name, Artist, Album Artist, Album, and File Type. (Having just Name and File Type, for example, would run into problems with cover songs.)

Thanks for continuing to work on this.

js

coxkevin · « **Reply #36 on:** April 03, 2003, 01:53:26 am »

Quote

Steve,

I can see why you prefer to keep "duplicates" defined in terms of database criteria. You're right that dropping Bitrate from the criteria has negative effects in some cases, but it's worse to have MP3 VBR and OGG not work at all.

On balance, my suggestion is that you define "duplicate" as having the same database entries for Name, Artist, Album Artist, Album, and File Type. (Having just Name and File Type, for example, would run into problems with cover songs.)

Thanks for continuing to work on this.

js

JS & Steve,

If I'm following the discussion correctly, the solution you are talking about is to transcode only when changing from one format to another (e.g. APE to MP3). Steve, if you remember, you put in the capability to transcode within a format (e.g. MP3 320 to MP3 160) to allow people (like me) to keep a high quality collection on their PC and downsample the songs when transferring them to the iPod. Whatever solution you settle on, I beg of you not to undo the trancoding capability within a format.

Cheers,
Kevin

noborg · « **Reply #37 on:** April 03, 2003, 02:27:50 am »

Hi Kevin,

If I understand you correctly, I don't think there's a problem.

First, the "no duplicates" option is for reformat operations (file to file), as opposed to transcoding (in-line as files are uploaded to the handheld). Second, it's only an option. If you don't select it, then there are no restrictions on how many different versions of the same song you maintain (e.g., mp3 at various bitrates).

js

SteveG · « **Reply #38 on:** April 03, 2003, 12:54:12 pm »

js,

I implemented the changes you requested. They will appear in the next build. Thanks.

Kevin,

No need to worry, the transcoding on the fly will not change and the change I added is optional.

Steve

noborg · « **Reply #39 on:** April 03, 2003, 04:58:51 pm »

Steve,

Tried the new "skip duplicates" with MC 142; seems to work just fine! Many thanks. The ape/mp3 workflow is pretty smooth now.

On the upload speed issue that we've discussed a few times, I've done some more testing.

First, let me mention that synchronize works great -- fast, and (especially with recent changes) very useful. In fact, I will likely switch to using it so the speed issue when dragging playlists is likely moot for me.

But there's a problem. The following is consistent on my system (whether or not I freshly format the iPod):

1. create playlist with 1000 songs

2. drag to iPod

3. The "updating" popup scrolls to 999 in about 12 seconds (reasonable). But then nothing happens for another 70 seconds until the screen clears.

4. click on the iPod; takes about 25 seconds before the queued files are displayed.

Also, the size of the upload indicated does not take into account duplicates. For typical usage, this is misleading and it makes it difficult to judge how much space really is available.

js

SteveG · « **Reply #40 on:** April 04, 2003, 01:13:24 pm »

js,

The speed issue is now greatly improved, but you will have to wait until the first build next week to see it.

I will also get to the duplicate size issue.

Steve

SteveG · « **Reply #41 on:** April 07, 2003, 06:53:08 am »

js,

Today's build will handle the duplicate file size issue as well.

Steve

noborg · « **Reply #42 on:** April 09, 2003, 02:38:28 pm »

Hi Steve,

Sorry for the delay. I tested MC 9.0.145. Both the speed issue and the duplicate file (size) issue have been solved. Thanks!!!!

Unfortunately, a significant bug (fixed a few builds back) has reappeared. When you drag a smartlist to the iPod, the filter view is ignored (so in my case you get the full set of ape and mp3 files queued). And the same thing happens with synchronization.

This is major, so (given the development stage), I'll also post to the beta list.

js

SteveG · « **Reply #43 on:** April 10, 2003, 07:20:00 am »

js,

This should be fixed in the next build.

Thanks.

noborg · « **Reply #44 on:** April 11, 2003, 07:53:54 am »

Indeed, it appears to be fixed in 9.0.147. Thanks Steve.
js

jeffh · « **Reply #45 on:** May 15, 2003, 09:09:48 pm »

Did something change to to the skip duplicate functionality in convert audio? After my recent upgrade to the latest build it does not seem to be skipping them. I have an mp3 version of the file in the library, but it want to do it again... Anything I can look at in the tags to make sure my files are the same?

SteveG · « **Reply #46 on:** May 16, 2003, 06:25:13 am »

Jeffh,

I do not think anything changed. If "Skip Duplicates" is enabled, MC should skip conversion on any file which has the same filename, file type, artist, and album of what you have set in the converter.

Does your mp3 file that exists in the library have the same filename, artist and album of what you are converting?

Steve

jeffh · « **Reply #47 on:** May 16, 2003, 01:37:24 pm »

Quote

Jeffh,

I do not think anything changed. If "Skip Duplicates" is enabled, MC should skip conversion on any file which has the same filename, file type, artist, and album of what you have set in the converter.

Does your mp3 file that exists in the library have the same filename, artist and album of what you are converting?

Steve

Yes, in fact I selected the whole library and it even reconverted an mp3 into an mp3 again... It seemed to try and make many more duplicates then skips...

SteveG · « **Reply #48 on:** May 17, 2003, 05:40:28 pm »

JeffH,

Lets pursue this more on Monday when I can work on this.

Steve

SteveG · « **Reply #49 on:** May 19, 2003, 06:08:48 am »

JeffH,

Can you email me a file that you know fails on your system with the exact settings you have set for your conversion so I can try to duplicate this here?

Thanks,

Steve ( steve @ jriver.com)

INTERACT FORUM

Author Topic: iPod workflow for parallel APE and MP3 (Read 10401 times)