Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[BryanC]

I use the conversion cache religiously to speed up handheld transfers. I usually use the HQ MP3 profile (320 kbps) for this purpose.

I am currently on a bandwidth limited connection and attempting to use audio conversion on my library client using the LQ profile (64 kbps). The problem is that any tracks that exist in the conversion cache (as a result of a handheld sync) are being transferred at 320 kbps (and thus I have major buffering issues).

Is there a way to circumvent this? If not, I would suggest that the conversion cache store the quality profile in a tag so that it can be read when library server or handheld sync accesses the cache in order to determine if the file fits the requested quality profile. It could then do one of two things depending on a user setting:

1. Create an additional cached file of the requested quality

2. Ignore the cache and convert on-the-fly

This would have the positive side effect of allowing different quality profiles to be served to different devices. For instance I have a storage-limited handheld device with a poor DAC that I prefer to use low bitrate audio files on, while I have another device with a much better DAC where I prefer to use higher quality files. A conversion cache with multiple qualities (or a new conversion on-the-fly) would allow both profiles to co-exist. Option 1 requires a much larger cache (not a big deal with today's HDD sizes) while option 2 allows more flexibility without additional storage space (at the expense of real-time conversion latency).

[BryanC]

I just ran into another side effect of using the cache.

The file that is created is dependent on the state of the DSP in effect during the handheld sync. On some devices (for instance, my car radio) I enable the DSP effects to apply replaygain to the files on conversion, whereas on other devices I do not. This means that my cache contains an assortment of files with and without the DSP applied.

The problem is such a nuisance I'm disabling the cache for the time being.

[BryanC]

Bump.

I'd also like to recommend just storing the profile information in a special tag (low, medium, high) and then have the handheld sync or library server read that tag and if it matches the selected profile, to use the file, and if not, to do one of two things:

1. Encode a new file for the sync or to be served over the library
2. Optionally store the new file in the cache alongside the existing cache files with different quality profiles (make this a user option since it could require a fair chunk of storage if multiple quality profiles are used)