View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002423 | MMW v4 | Conversion/Leveling | public | 2006-03-13 14:59 | 2008-03-26 03:28 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Fixed in Version | 3.0 | ||||
| Summary | 0002423: AAC (m4p, m4a) Encoding Add-on | ||||
| Description | MM should have AAC encoding capabilities available via a fee-based add on. Such an add-on could be purchased by users as an add on when they buy MM or subsequently. It would probably need to be based on licensed code since current open source AAC implementations are quite poor. Current implementations: -http://coreaac.corecodec.org/ -http://www.audiocoding.com/ -https://helix-producer.helixcommunity.org/downloads This needs to be specced and prioritized. | ||||
| Additional Information | Btw, check out the following for info about other implementations: http://wiki.hydrogenaudio.org/index.php?title=AAC_implementations http://www.zplane.de/showPage.php?SPRACHE=UK&PAGE=products9 (Interestingly, the folks at zplane also sell a beat detection sdk) | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1141 | ||||
|
|
Since it's important to include this MM 3.0, we should review which aac implementation would be the best for us (based on licensing costs). |
|
|
Per discussion _can_ go ahead with using both FAAD and FAAC from: http://www.audiocoding.com/modules/mydownloads/ Reason is: From what I read, both FAAC and FAAD are now decent implementations and from a licensing perspective, FAAC is no problem (since LGPL), however FAAD is GPL but we're not distributing the plugin _with_ MediaMonkey, so there's no problem! If we take this route we would be subject to the following restrictions: a) The license terms for FAAD would be GPL (i.e. we can charge for the binary, but the source is redistributable--just as FAAD is) b) When users download the plugin, the plugin should also include FAAD sources Note: there's no restriction against charging for binaries of GPLed code. As far as IP licensing fees go, they are: $.50 (decode) + $1.00 (encode) Implementation note: this can be implemented as a standard set of plugins (no serial# type of security is required since it'll just sell for a couple of dollars to cover licensing/distribution expenses). |
|
|
Assigning to Pavel to implement a format plug-in that will both decode and encode aac/mp4 files using FAAC and FAAD2. This is the whole specification for now, when it's implemented more things will be discussed: - UI interface of the plug-in (i.e. mainly encoding options of FAAC) - Distribution details of the plug-in |
|
|
Based on options of FAAC, the encoding UI should look like: Type of bitrate: [Variable bitrate (VBR) | Average bitrate (ABR)] For VBR: Quality: [----------[]----------] { A slider + a numeric representation, as in FAAC where quality is from 10 to 500} For ABR: Avg.bitrate: __96_ {SpinEdit} We could also add some advanced options, probably, but it isn't necessary at this moment: Bandwidth: _Automatic_ [v] kHz {Value: Automatic|16|18|20|22 +others?} AAC MEPG version: _4_ [v] {2 or 4} ... |
|
|
Currently it seems to work, but there are problems with settings - when I set ABR, the next time it's reset to back to VBR. Also the small window in Conversion dialog should either show ABR or VBR settings, not both. |
|
|
note: we should include ALAC encoding as well, however, if this is difficult, it can be deferred to an update release. |
|
|
I don't know about any available source for ALAC encoding, only Apple has it and recently dbPowerAmp implemented a plug-in. So, complexity of this feature really depends only on availability of sources... |
|
|
I fixed showing ABR or VBR settings in the small window of the conversion dialog. |
|
|
Note re. distribution: if we make this available via element5 store without any sort of license key, then the software would have to be downloaded from a protected element5 site. In order to ensure that updates are available, we'll need to ensure that the software is somehow available for 1 year. |
|
|
Upon further discussion with Jiri, we discussed the idea of making a limited version of the encoder (30-day time limit is the maximum permitted for trials) that would be provided separately from MM for those who wish to try it out. Options are: a) bundle trial version of FAAC with MM, but ONLY IF FAAD2 isn't icluded (since FAAD2 is GPL whereas FAAC is GPL) b) have trial version of FAAD2/FAAC available separately The paid version would include both FAAD2/FAAC and would be sold as as add-on via our store. The add-on could work with either MM Gold or MM Free. Note: I expect that option b) might be better in the short term due to timing/localization issues. In terms of providing upgrades to the plugin, we need a solution that: -generates few support calls -requires little manual intervention -allows for upgrades to both Trial and Paid versions of the plugin Options discussed are: c) notifying users (by mail) and making a zero cost coupon available. This is labor intensive. d) notifying users (by mail or extensions update mechanism) and making an upgrade available via a hidden url. . i) Update is the Paid version of the app. This is relatively simple to do, but means that some users may get access to the plugin for free. . ii) Update is a version of the app that upgrades the DLL, but doesn't change the free/paid status of the plugin. This eliminates security issues, but may not be technically realistic. Let me know what you think. |
|
|
I think that this would be the best solution: 1. The paid version downloaded from Element 5 would store somewhere in registry a key specifying the version paid for - e.g. something like 'v1.x'. 2. The standard version downloadable from our web would be time limited (or non working at all?) and in case it would detect 'v1.x' value in registry, it would enable the full functionality. 3. The only problem can happen in case the user reinstalls computer or somehow loses the information stored in registry. We can either try to solve it somehow, or leave it to user's responsibility to keep the original installer - otherwise that small registration fee would have to be paid again. |
|
|
Sounds good. |
|
|
Assigning to Rusty to specify strings to be shown to user - probably something similar to what we show for mp3 encoding trials. Assign to Ludek to implement it then. |
|
|
Product Name AAC Plug-in (the different versions of the plugin will be distinguished by their filenames) Message 1 (After installation): Thanks for installing the MediaMonkey AAC Plug-in for AAC encoding. ---This text is only for the trial version--- Due to licensing restrictions, the trial version is limited to 30 days after which you'll be prompted to upgrade. ---End of extra trial version text--- Please restart MediaMonkey for the AAC Plug-in to complete the installation. Message 2 (at 30 days): Due to licensing restrictions, the trial version of the AAC Plug-in is limited to a 30-day trial period. For unrestricted AAC encoding please upgrade. [Upgrade] [Cancel] Note: Upgrade button should link to something like registeraac.mediamonkey.com |
|
|
please review. |
|
|
Assigning to Ludek to implement this way. Let's discuss details over IM. |
|
|
Implemented. Both installers are uploaded to our FTP (to the root folder as MediaMonkey_AAC_Plug-in_1_0.exe and MediaMonkey_AAC_Plug-in_1_0_Trial.exe) |
|
|
I just tested V1.0 and there are a few tweaks that need to be made: 1) Installer defaults to \Program Files\MediaMonkey. This is fine, however, when the user, thinking that it must go to the plugins directory changes the path to \Program Files\MediaMonkey\Plugins, then it installs to that directory and doesn't work. Is there any way to prevent this? 2) In the AAC Settings dialog, the Title bar indicates FAAC Settings. Shouldn't it show AAC Settings? (most users don't know what FAAC is). 3) In the AAC Settings dialog, when VBR is chosen, the quality settings are off by 1%. i.e. if the user chooses the 50% marker, then the number displayed is 49. 4) In the AAC Settings dialog, when VBR is chosen, the user has no idea what the Quality % means in terms of a bitrate. For any given %, MM should indicate an ~xxkbps bitrate. See the MP3 or OGG configuration screens to see what I mean (note: this same bug is a problem on the WMA>VBR config screen). 5) Similar to above, when the user is choosing settings, it should display the bitrate in the summary box of the Auto-conversion rules selector dialog. e.g. it displays as: Type of bitrate: VBR VBR Quality: 50% What should be displayed is: Type of bitrate: VBR Quality: 50% = ~yy kbps 6) Once the user chooses a setting, it displays incorrectly in the Auto-conversion dialog. e.g. it displays as: Format on Device ---------------- M4A (Type of Bitrate: VBR[]VBR Quality: 50%) It should display in the same manner as the OGG encoder and without the square artifact e.g.: M4A (VBR xx% = ~yy kbps) 7) Neither iPod nor MediaMonkey can play tracks encoded by MM using Auto-conversion to m4a (settings encode to M4A, VBR 50%). Both MM and iPod just skip through the tracks. Note: straight conversion to m4a works--the problem is with auto-conversion. 8) With the plugin installed, MM is no longer able to play back tracks that have been purchased from iTunes. If DRM is detected, then the 'default' plugin should be used. 9) Default encoder values for VBR are way too low. I'm guessing that it should be around 70% for VBR (vs default of 20% which yields bad quality). |
|
|
2) - Unfortunatelly the string "AAC settings" is not localized so I replaced it just by "Settings" 3) - Fixed. 7) - Fixed. 9) - Fixed. I am going to fix the rest ASAP. |
|
|
Re items 4,5,6: fixed + implemented GetEstConvSize method in order to be able to estimate the file size, but (related to item 9) in case of VBR the bitrate estimation was quite hard job, because the % setting has rather a logarhitmic character so I had to found an approximated function for this so that bitrate could be estimated. Therefore I changed the default VBR value to 50% (177kbps) instead of 70% (193 kbps). Note 1: that 10% is 99kbps, 20% is 133kbps and 100% is 210kbps -> logarithmic character Note 2: the 20% they have as default for the front end sample application of FAAC libs, but they represents 20% as 100, i.e. <0%,100%> is <0,500> + resolved problems with setting of ABR/VBR - there were a bugs and settings was not performed right |
|
|
Fixed also item 1 ( Installer defaults to \Program Files\MediaMonkey\Plugins now) + added prevention from breaking the trial date expiration by installing the trial version again. So now is fixed all except the item 8) - I will probably need to discuss this with Jiri - I'mnot sure whether this will be possible without any changes to main app. |
|
|
Fixed also item 8, i.e. if one format plugin cannot decode a file (e.g. DRM protected) then another available format plugin should try to decode this file. But there were needed changes to the main app so the item 8 is fixed in build 1141 and the rest (1-7,9) is fixed in the updated installer packages(MediaMonkey_AAC_Plug-in_1_0.exe and MediaMonkey_AAC_Plug-in_1_0_Trial.exe) |
|
|
Implemented seeking for AAC and enabled AAC decoding - seeking is now implemented for all file types: AAC, MP4 (M4A, M4B) and ALAC and decoding is fully supported. |
|
|
Verified 1.0.1. except item 8) -- drmed m4p tracks don't play. With the plugin installed, DRMed tracks can't play. Moreover, one one occasion, after I tried to play a DRMed track, I was subsequently unable to play non-DRMed m4a tracks afterwards--CPU went to 100% on one CPU and MM was frozen. |
|
|
Re: drmed m4p tracks don't play This is not related to this plugin, but it seems to be a regression introduced betweeen build 1134 and 1135. I have reopened 0004487 for this. Another bugs related to this plugin reported here: http://www.mediamonkey.com/forum/viewtopic.php?t=27472 |
|
|
Verified. |
