Add file compression
NicoHood opened this issue · 12 comments
I am wondering if it would be possible to place the mp3 file in a directory outside the ipod and then transfer them. We could then also reduce the filesize with compressing the files.
Itunes also has this option and I really appreciated this. I normally only have 320kb/s mp3, but on an ipod it its really low space. Having an option for 192kb/s or others would be really nice. If you dont need to manually do it and just select a folder from your music library, copy and shrink it, that'd be perfect.
Any chance to see this?
Hmm, a valid idea, can be done using a ffmpeg/libav dependency. However, I am unsure of the design where this feature will fit in. One option would be to have an additional optional --import-music-dir parameter which defaults to the ipod location. The additional --bitrate will convert files before copying to ipod location (With a replace warning if --import-music-dir is the same as ipod location)
I'd say those 2 features could work independent, but would profit from each other.
The optional dir would be required since a compression allows more files to be added after compression. But in general it would be a nice idea, so say the script "pick this path". So optional input/output params would be nice.
Compression itself makes sense and can be done with some decoder as you suggested. --bitrate (-b) would make sense. Default is no optimization.
Looking at the source I think we need to change a few more things to make this API more flexible.
I also though of just appending files. Like you select an input source Linkin Park and just want to add it to the Ipod database. And if those songs are already available, just ignore them or ask if you should replace them. That is also what the ipod software does, which saves a lot of time. So you have a local db which you can sync.
This requires to write the database again. You need to scan the whole ipod for files and then rewrite the database. Thinking about this some time, I found out we just dont need to change that much and keep things intuitive.
We just need to add an import function. Within this import it simply copies data to the ipod. We can add those features then:
- Use an external source
- Add optional compression
- Normally unsupported formats can be converted.
- Original placed files are not touched (mixed low and high quality if you want to)
After importing the normal database generation function runs. You have a new database which has the imported and existing files in place. This way you can drag&drop files onto the ipod.
Also other ideas would be to:
- Place the script into the ipod and make it executeable via double click
- Add a settings file, to link to an import path and set bitrate etc.
- The voiceover things I suggested in the other post
The importing workflow and features sounds good to me, nicely summed up. I think importing it the same way as Rhythmbox (Artist/Album/Track.mp3) should be the good thing to have, conflicts being resolved through suffix renaming.
I think rather than stuffing things inside the single shuffle.py file, importer should get its own importer.py which can be used by shuffle.py. Adding this feature should not be challenging, will just require handling edge cases and testing.
Regarding the other ideas
- I don't see much use for it except for narrow use cases. If a user needs it, he can easily do it without any changes in the script.
- Settings file can follow the importer thing.
- Discussion on that issue page.
Adding a 2nd script sounds nice. Auto organizing the sounds might be an idea, but I just though it would copy the structure of a folder into the ipod.
About idea 1) I would just write it as additional tip into the readme. Other suggestions will follow. But we should keep structured and dont mix up issue topics.
Looking forward to see a very nice api here. Rythmbox and other programs could use this as underlying api too, if its good and flexible enough.
I currently tried to add lame encoder for smaller files.
I used lame --vbr-new input.mp3 output.mp3. The idea was to move the file into `/tmp/shuffle/ and convert it backwards.
However there is a problem with converting files over and over again. We could create a special database file for the converted files (but removing files will not be recognized) or special .filename.isconverted files (which will spam the folder, or will be missed to delete when hidden).
The best solution would be to check the quality before converting. Or as discussed an import/convert script that does the job. A special script with input/output folder param would possibly the best. Maybe just in normal bash, not python. If no output is provided it could just overwrite the files (as described above).
This tool suits my needs:
https://github.com/ZivaVatra/flac2all
You can convert a whole folder to mp3. You can copy additional data, you can exclude dirs, you can skip already encoded files etc.
Other alternatives can be found here:
https://wiki.archlinux.org/index.php/Convert_Flac_to_Mp3
The input files have to be flac though, but the ffmpeg script for example should also work with other inputs. The mentioned program above has even multicore support, so its super fast. I just need to have flac sources though.
We could add this information to the Readme and close this issue. Or we integrate the program as optdep and somehow add a param for it. But I dont think this makes much sense.
soundconverter Is also a very nice app. I just copy everything to /tmp (ramdisk) and the convert the files via replace. Then finally move them to the ipod and generate the database.
Lets just write our own ffmpeg scripts? It is quite straightforward, and we also avoid dependencies. ffmpeg can take up any audio file and converts it to target format with specified bitrate. I will prepare a demo script and get your feedback on it.
Actually this is not required. I am really happy with the last solution (soundconverter) which can also be used in batch and gui mode. You could also just select input folders and output all of them to the ipod. So its extremely simple and straightforward. I think no additional script is required, it would just have less fetures.
I suggest to add the archwiki page and the soundconverter link to the readme and close this issue. For me that really solved the problem.
Okay, makes sense. We need not reinvent the wheel! Updated the readme
Thanks.
Do you really plan on switching to python3 now? If not I will update the pkgbuild with python2.
So far this script made a huge progress. I am really happy about that. Thanks for the good teamwork :)