Java 背包算法，大容量

我目前正在开发一个播放列表播放器，我面临一个问题。我的播放列表中有可变长度的空白，我想用特殊的音频文件来填充。这些文件的长度也是可变的，通常比我的播放列表中的间隔要短

这听起来像是一个经典的背包问题，所以我尝试实现这个算法。这对较小的间隔很有效，但每当我有30分钟的间隔时，算法就会使用大量内存。这是意料之中的，因为我用它来解决问题

背包的容量为{gap in millises}，背包项的重量为音频文件的重量（毫秒）

这是非常有效的。所以我想知道我是否可以使用不同的算法，或者将重量和容量更改为更小的变量。到目前为止，我一直在考虑用一个任意的数字来除所有的东西，但是如果我这样做的话，我会失去精度

有人有什么想法吗

编辑：

我有大约500个填充物来填补空白。改变音高是不可能的。 填料组应具有完美的解决方案。

---

我真的很想要毫秒精度，但我可以在100毫秒以下生活

您可以使用迭代深化近似法，在该近似法中，您可以使用适合的所有最长填充物来填充间隙。然后删除它们（从短到长），在每一个之后使用动态算法求解剩余空间。由于每次拆卸都会增加剩余间隙的长度，因此每个问题都会更加困难。一旦您的时间或内存用完，请停止，并使用上次生成的解决方案。

您说了播放列表，因此我假设您有歌曲，一首典型歌曲大约需要3分钟，因此您的解决方案大约需要10首歌曲。因此，您可以将所有时间除以50，然后一首歌曲的典型错误为正负25毫秒，因此对于10首随机歌曲，错误通常为（25毫秒*sqrt（10））<100毫秒。如果你想对错误有更好的保证，那么你可以将你的歌曲时间和目标时间除以20或10，但是如果你将时间除以10，那么你应该很少会得到超过100毫秒的错误。除以10意味着你将内存除以10，得到精确的O（WN）动态规划解，这样，如果你在边界上，它就可以区分适合内存和不适合内存。

你需要毫秒精度吗？若然，原因为何？你能控制间隙的长度吗？一个小小的背景会有很大的帮助。是否必须以最佳方式填补这一空白？当新的差距低于某个阈值时，也许你应该停下来。这听起来很奇怪。30分钟的间隔从何而来？为什么它必须完美贴合？音频文件可以很容易地拉伸百分之几而没有任何明显的差异，也许这会有所帮助？我用更多的上下文编辑了原始问题。值的预计算是可能的还是动态的？这就是我现在使用的，似乎我无法进一步改进算法。我要尝试一些不同的数字，看看什么最有效！